[zeromq-dev] Poll on sockets OR child process

Pieter Hintjens ph at imatix.com
Fri Dec 20 09:36:11 CET 2013


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
<pelletier.michel at gmail.com> 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 <ph at imatix.com> 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
>> <pelletier.michel at gmail.com> 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 <ph at imatix.com> 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 <greg at gerg.ca> 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
>> >> > <greg at gerg.ca>                       @gergdotca
>> >> > _______________________________________________
>> >> > zeromq-dev mailing list
>> >> > zeromq-dev at lists.zeromq.org
>> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> _______________________________________________
>> >> zeromq-dev mailing list
>> >> zeromq-dev at lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> 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