apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_proc_other_child_read examined in depth
Date Wed, 29 Jan 2003 05:48:44 GMT
At 02:28 PM 1/28/2003, William A. Rowe, Jr. wrote:
>Now how is apr_proc_other_child_read related to its description above?  There is no check
>for the current health of the process.  apr_proc_other_child_read appears to really be
>apr_proc_other_child_died(), a function we can't support on win32.  Why not?  Because
>don't have 'child processes' that raise exceptions.  Yes - we can have them raise an event,
>add them to a poll that signals when the process exits (if we have the apr_proc_t we created
>when we spawned the child - that apr_proc_t contains a handle that can be sampled.)

I'm really liking this basic idea... some sort of APR construct to poll processes.
On win32 that would be a WaitForMultipleObjects (possibly, several waits within
several cascading threads because Waitxxx APIs have a limit of 64 objects) and
on Unix that would be the basic signal handling.

Still no concrete solution, since this isn't trivial to design.  Just wanted to update
the status.

BTW - there are two different write exceptions; EWOULDBLOCK/EAGAIN and then
any other really nasty errors from write-to-pipe.  I believe we need a notification fn
after apr_write-to-O_C-pipe that would deal with the non-pipe-full conditions.  If the
pipe handle is *really* broken we should deal with that case.

However; that still isn't enough.  Because the pipe never really breaks.  We keep
the child handle around in the parent so we can respawn the other child.  Without
that handle sibling children wouldn't share the parent side of the pipe.  So it is all
really a catch 22.

Just more observations, another pair of eyeballs might come in handy.

-1 on 0.9.2 till this issue is resolved.


View raw message