[zeromq-dev] Poll on sockets OR child process

Michael Haberler mail17 at mah.priv.at
Sun Dec 22 09:25:37 CET 2013


Michel,


Am 22.12.2013 um 02:58 schrieb Michel Pelletier <pelletier.michel at gmail.com>:

> On Fri, Dec 20, 2013 at 1:06 AM, Michael Haberler <mail17 at mah.priv.at> wrote:
> 
> Am 20.12.2013 um 00:56 schrieb Michel Pelletier <pelletier.michel at gmail.com>:
> 
> > So in (pyczmq) code I was thinking something like:
> >
> >
> > @zloop.signal_callback
> > def on_signal_event(loop, item, arg):
> > ...
> >
> >
> > loop = zloop.new()
> > zloop.signal(loop, signal.SIGHUP, on_signal_event)
> 
> the issue I see: this is still the 'spontaneous invocation' handler model - meaning asynchronous delivery; you arm it, this fires whenever it feels fit
> 
> I think the major upside with using signalfd in the loop is having control over when the handler is invoked, by treating signals like any other fd event and deal with them synchronously
> 
> I'm confused.  What you're describing is what I'm proposing.  I'm not proposing using a traditional asynchronous signal handler that could interrupt your program at any point, but for the above pseudocode to register a file descriptor from signalfd with the zloop poller, and when the loop is running, for the function to be called when the descriptor is ready.  This seems to me to be entirely the point of signalfd.

sorry - my bad. I misread your proposal - it's in line with the idea, just go ahead.

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?

- Michael

>  
> -Michel
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list