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 <[email protected]>: > > > 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
