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: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 16:41:50 GMT
At 08:59 AM 2/5/2003, Jeff Trawick wrote:
>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.

Right... because those platforms that don't 'react' to the child_errfn are
*generally* the platforms that will return a failure result from invoking
apr_proc_create.  So we don't really lose anything by introducing your
new schema, and we have everything to gain.  ++1

But what about simply an apr_proc_create_ex() function that accepts
the callback.  I suspect this might be cleaner, because it will be easier
to find code that failed to provide such a callback (which is really a bug,
IMHO.)  Like socket_create we can drop the _ex from APR 1.0 and always
add that arguement to socket_create.  The code will probably be easier
to read, in any case.  This should be supported on all platforms, it's simply
a noop where fork() wasn't involved.  Either way, though...

Please make the callback take the apr_status_t result, the apr_procattr_t
that failed and a pool.  Let the caller format it into a message if they like,
rather than creating more language-specific strings within apr itself.  The
callback should be able to take anything back out of the apr_procattr_t that
it's interested in.  And they should be able to take their context back out
of the apr_procattr_t rather than another userdata field.  (Heck, they could
even create pool data if they needed.)

Again, great idea!


View raw message