Jeff Trawick wrote:
Index: include/apr.h.in =================================================================== RCS file: /home/cvs/apr/include/apr.h.in,v retrieving revision 1.118 diff -u -r1.118 apr.h.in --- include/apr.h.in 22 Jan 2003 18:25:59 -0000 1.118 +++ include/apr.h.in 5 Feb 2003 14:40:52 -0000 @@ -139,6 +139,7 @@ #define APR_HAS_SENDFILE @sendfile@ #define APR_HAS_MMAP @mmap@ #define APR_HAS_FORK @fork@ +#define APR_HAS_CHILD_ERRFN @fork@
Thinking ahead, maybe this should be more general, and should be some concise name that means that apr_proc_create() *may* use fork().
Two other things I'm thinking of:
. adding a separate attribute that tells apr_proc_create() to burn cycles prior to fork() to look for potential errors that would be encountered in the child (e.g., make sure the executable exists and can be executed, make sure any specified curdir exists)
we would want one feature macro that covers the function of my patch as well as the burn-extra-cycles option
. at least one platform where we currently use fork+exec has more efficient spawn-type function... if we determined at run-time that we could do everything the app wanted via spawn, we'd be bypassing the code that made use of these new proc attributes
hence the phrase "*may* use fork()"
