OK, so perhaps a class that turns signals of any kind into messages on a pipe socket?
I'm searching for abstractions here. It's not profitable to expose low level functionality to users, especially when like signals, it conflicts with our message based model. On Fri, Dec 20, 2013 at 12:51 AM, 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
