[zeromq-dev] Poll on sockets OR child process
Michel Pelletier
pelletier.michel at gmail.com
Fri Dec 20 00:56:38 CET 2013
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)
-Michel
On Thu, Dec 19, 2013 at 3:51 PM, 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131219/6ba36c01/attachment.htm>
More information about the zeromq-dev
mailing list