apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 16:55:12 GMT
Greg Ames wrote:

> > Alternatively, APR could allow the application to get called in the
> > child process in the failure cases and allow it to do whatever is
> > appropriate (log a message, synchronize with the parent process, etc.).
> Couldn't the stat's, chdir's, etc. be done only after a failure to keep
> the overhead out of the mainline path?  Then each app wouldn't have to
> rewrite the basic diagnostic code.

After a failure of exec() or chdir() we already know the reason of the 
error, so such extra checking in the error path is not helpful.  The 
problem with waiting until after something fails in the child is that 
there is no straightforward way for APR to communicate the specific 
reason for failure to the parent.  The parent (the app that calls 
apr_proc_create()) is long gone from its call to apr_proc_create().  All 
that happens is that the child exits with code -1, and the parent can 
find out by calling apr_proc_wait().

A particular application may have a suitable way to communicate this 
info to the parent in its own code, and APR will make that info 
available to the application via the child error function.

View raw message