apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 16:31:52 GMT
Jeff Trawick wrote:
> On Unix, some failures of apr_proc_create() are not noticed in the 
> calling process and so apr_proc_create() returns APR_SUCCESS even though 
> it failed.

++1 in concept.  It has bugged me for a long time that httpd 2.0 only logs 
"Premature end of script headers" no matter what is wrong with a CGI.  ISTR that 
1.3 provided better diagnostic info, perhaps at the cost of more overhead.

> Some of the potential failures could be discovered in the parent by 
> using extra syscalls (e.g., use stat to make sure the program actually 
> exists and can be executed by this user, use stat to make sure the 
> desired working directory actually exists and can be chdir-ed to by this 
> user).  It isn't appropriate to burn the required cycles by default, but 
> it would be nice to allow the app to turn on this extra checking, since 
> failures of apr_proc_create() can be handled much cleaner if the 
> function returns an error status.
> 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.

Having an optional callback in the app do the logging is a good idea.  It gets 
around the problem of the library spewing messages to stderr which the app may 
not want.


View raw message