apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/threadproc/win32 proc.c
Date Fri, 07 Feb 2003 12:56:46 GMT
trawick@apache.org wrote:

> trawick     2003/02/06 10:50:31
>   Log:
>   Allow apr_proc_create() to call an app-provided error reporting
>   function when apr_proc_create() fails in the new child process
>   after fork().  The app-provided error reporting function will only
>   be called on platforms where apr_proc_create() first calls
>   fork() to create the new process.
>   Index: apr_thread_proc.h
>   ===================================================================
>   +/**
>   + * The prototype for APR child errfn functions.  (See the description
>   + * of apr_procattr_child_errfn_set() for more information.)
>   + * It is passed the following parameters:
>   + * @param pool Pool associated with the apr_proc_t.  If your child
>   + *             error function needs user data, associate it with this
>   + *             pool.
>   + * @param err APR error code describing the error
>   + * @param description Text description of type of processing which 
> failed
>   + */
>   +typedef void (apr_child_errfn_t)(apr_pool_t *proc, apr_status_t err,
>   +                                 const char *description);


I may have had a change of heart on providing this information (text or 
enum or whatever) about which step in processing actually failed :)

We don't actually give this info in the rest of APR.  Not that more info 
is bad per se, but making promises in one small place that are woefuly 
unfullfilled everywhere else is a little disturbing.


Mime
View raw message