Am 22.12.2013 um 20:33 schrieb Michel Pelletier <[email protected]>:
> On Sun, Dec 22, 2013 at 12:25 AM, Michael Haberler <[email protected]> wrote: > Michel, > > > Am 22.12.2013 um 02:58 schrieb Michel Pelletier <[email protected]>: > > > On Fri, Dec 20, 2013 at 1:06 AM, Michael Haberler <[email protected]> > > wrote: > > > > Am 20.12.2013 um 00:56 schrieb Michel Pelletier > sorry - my bad. I misread your proposal - it's in line with the idea, just go > ahead. > > > Awesome I'll try my hand at a PR. excellent. Happy to help with the czmq side. Eventfd might be worth doing in one wash. I guess if we'd be going for API compatibility Windows we'd have to decide beforehand if we want to retain the struct signalfd_siginfo as is on Linux and clone it for Windows, filling it in as best as one can in a Windows signal handler as it might spill into the API; the other route would be abstract out struct signalfd_siginfo altogether. I'd rather go for the first option; open for suggestions. btw this Python wrapping works fine for me doing beacon unicast reception/sending for DHCP-style discovery: https://github.com/mhaberler/pyczmq/commits/zbeacon-unicast - Michael > For windows, to retain the API, maybe there's a way to emulate the behavior > by using a pipe between the signal handler (or is an IOCP port handler?) and > the loop, and queue the equivalent of a signalfd_siginfo structure? > > I have no knowledge of windows so I couldn't say, but I would love any > patches that add windows support to pyczmq, it's something I had to triage in > the beginning. > > -Michel > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
