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
