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 whether it's SIGCHLD or any other signal shouldnt matter; it might impact on zctx_interrupted though which is kind of a special case even if a common one I'm fuzzy how an equivalent mechanism to signalfd() can be done on Windows for a single API - Michael > > -Michel > > > > On Thu, Dec 19, 2013 at 3:51 PM, Michel Pelletier > <[email protected]> wrote: > But SIGCHILD isn't the only interesting signal here, there may be no children > and you're more interested in registering a handler for some other signal. > > -Michel > > > On Thu, Dec 19, 2013 at 3:16 PM, Pieter Hintjens <[email protected]> wrote: > I think it needs to be part of a process creation class, zproc or > somesuch; the cleanest way IMO to report events from child processes > is via ZeroMQ messages in any case. We do this in other classes which > use a message-based API. > > On Thu, Dec 19, 2013 at 10:18 PM, Michel Pelletier > <[email protected]> wrote: > > It seems like this is something that could be appropriately added to zloop? > > A signal registration function that internally added a signalfd an called a > > handler. > > > > -Michel > > > > > > On Thu, Dec 19, 2013 at 12:36 PM, Pieter Hintjens <[email protected]> wrote: > >> > >> Hi Greg, > >> > >> This is nice stuff. Process management is one of the incomplete areas. > >> If I was doing this in CZMQ, I'd have a class that managed child > >> processes and sent events (DIED, ENDED) back to the parent over a > >> pipe. > >> > >> -Pieter > >> > >> > >> On Wed, Dec 18, 2013 at 3:33 PM, Greg Ward <[email protected]> wrote: > >> > On 27 November 2013, I said: > >> >> I'm hacking on a task distribution system used internally here. It has > >> >> N masters sending tasks (shell commands) out to M workers, and then > >> >> doing stuff with the results. There's something that annoys me > >> >> slightly about the implementation: the worker runs each task in a > >> >> separate thread. > >> >> > >> >> IMHO it would be ever so much nicer to just spawn the child process > >> >> that runs a task, and harvest the results when they are ready. IOW, I > >> >> want to integrate wait() and zmq_poll() in a single event loop. > >> > > >> > Thanks again to Michael Haberle for the tips. Since this was > >> > non-obvious to me, I assume it will be non-obvious to others in > >> > future. So I made several working examples and wrote up a blog post: > >> > > >> > http://gerg.ca/blog/post/2013/zmq-child-process/ > >> > > >> > Comments/criticisms are welcome. > >> > > >> > Greg > >> > -- > >> > Greg Ward http://www.gerg.ca > >> > <[email protected]> @gergdotca > >> > _______________________________________________ > >> > 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 > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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
