Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030205093325.02b7f828@pop3.rowe-clan.net>
Date: Wed, 05 Feb 2003 10:41:50 -0600
To: trawick@attglobal.net
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PATCH] letting the app do something useful when
  apr_proc_create() fails in the child process
Cc: dev@apr.apache.org
In-Reply-To: <3E4126C5.7020309@attglobal.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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!

Bill