apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 14:59:17 GMT
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.

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.).

I think both features are important.  Using Apache as an example, I 
would imagine that for situations where apr_proc_create() is not called 
frequently (e.g., piped log program), it would be useful to turn on any 
available extra checking in the parent so that the best possible 
diagnostics can be given to the admin with minimal extra coding in 
Apache.  Such extra overhead is of no concern for a path that runs so 
infrequently.  On the other hand, when running CGIs (something the 
server may do very frequently), any extra overhead would be 
inappropriate given that we expect it to work in general.

This particular patch allows the latter approach -- let the app get 
involved when apr_proc_create() fails in the child.  This is useful with 
or without the ability to try to find potential errors in the parent 
since not everything can be checked.

Any concerns, particularly with respect to how the app determines if the 
feature is available?  I think it would be fine to make the feature 
always available but to simply note that on some platforms the 
application-specified error function would never be called.

View raw message