On Monday, 20 June 2016 at 19:39:42 UTC, Steven Schveighoffer
wrote:
On 6/20/16 12:29 PM, Vladimir Panteleev wrote:
On Monday, 20 June 2016 at 16:16:32 UTC, Steven Schveighoffer
wrote:
What is the OS support for waitid
(http://man7.org/linux/man-pages/man2/waitpid.2.html)? Seems
to have
support for async waiting of multiple processes (at least it
can
return immediately if no child has exited). One consideration
is how
responsive you need to be to a process exiting -- is it ok
for example
to be notified 500ms after the process exits? If so, you can
interleave timed waits for socket data with a check to see if
any
process exits. I've done this in the past for such things. I
don't
know how well this works for libevent though.
std.process has tryWait() if polling were acceptable, but I
would really
like to avoid it. Or have I misunderstood?
tryWait works on a single PID. From my reading of the docs, it
appears you can call waitid and no matter how many children you
have, if one exits, then it will capture that.
Ah, OK. But then so does SIGCHLD, asynchronously.
It would be nice if the Linux wait mechanisms were all
standardized similar to Windows. I think the only thing that
allows such universal access is file descriptors. Processes are
definitely a case where it's not easy to deal with the events.
Signal handlers suck as an async mechanism.
It's really not that hard. It's just that no one bothered to
implement this correctly in Vibe. Process or signal handling does
not seem to be a Vibe.d driver primitive.
Signals interrupt blocking calls such as select/poll. Even if you
don't have a signal handler registered, you could in theory call
tryWait or similar on every process ID you're waiting on in an
event loop idle handler. It's not very efficient, of course, and
degrades poorly as the number of processes and events grows.
You can also register a signal handler, and just ping a socket
pair (unmanaged on one side, managed by the event loop on the
other). This is what I do in ae.
As I recently learned, there's also signalfd. With that, had
Vibe.d had a primitive to wrap a file descriptor into a stream it
can manage, it would be as simple as reading from it. But it
doesn't seem to have one so I guess you need to use
createFileDescriptorEvent and the raw C read() function.
But my point was that you can poll on every start of event
loop, and handle process exits if they are ready, and then
every 500ms or so if no i/o becomes ready. In practice, this
should be pretty responsive, unless you are only doing process
execution and no i/o. And half second delay between process
exit and handling of result is pretty small even in that case.
Sure, but to be honest that's nothing but an ugly hack. :) Even
if not for the 500ms delay - every bit adds up, and timers are
much worse than event handling on e.g. mobile devices than
servers, because they incur a CPU wake-up and then end up doing
nothing most of the time.
Anyway, I'll probably do one of the above, thanks.
