apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 15:54:21 GMT
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()"


Mime
View raw message