httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: svn commit: r264737 - /httpd/httpd/trunk/docs/manual/stopping.xml
Date Wed, 31 Aug 2005 11:53:09 GMT
On Wed, Aug 31, 2005 at 06:54:03AM -0400, Jeff Trawick wrote:
> On 8/31/05, Colm MacCarthaigh <> wrote:
> > On Wed, Aug 31, 2005 at 10:24:49AM +0100, Joe Orton wrote:
> > > Apologies for the previous empty mail ;)
> > >
> > > If the performance difference is that small then mod_cgi is definitely a
> > > better default IMO: it has much better stderr handling (the "CGI bucket"
> > > stuff) and it will log to the correct vhost-specific logs.
> > 
> > +1 on changing the default, cgid can remain available for .1% freaks.
> I keep a quote from Ulrich Drepper on the wall behind my monitor
> (somewhere between the TCP state transition diagram and how to write a
> DVD on Linux):
> "No threaded program must use anything but _exit or exec after fork."
> apr_proc_create() does a lot more than that.  It isn't that I believe
> the statement to be the absolute truth given infinite programming time
> and highly constrained web server APIs (neither of which we have), but
> I believe it is wise to follow anyway.

"must not use anything but async-signal-safe functions" is actually what 
the standard requires FWIW.

> Sadly, mod_ext_filter calls apr_proc_create() similar to mod_cgi and
> is subject to race conditions in threaded servers under heavy load,
> with pipe handles open in the wrong processes which prevent the
> children from seeing EOF on their stdin (due to magic of fork, handles
> intended for a particular child get duped in another child).  A lock
> to be held by any code dorking with file descriptors or forking is
> needed to prevent file descriptors from being duplicated unexpectedly
> in children.

Ah, I always forget about this "people using threaded servers are 
doomed" scenario.  I guess all the people voting to make worker the 
default MPM do too...

Regardless of cgid vs cgi, how much of this is it feasible to fix?  APR 
has to require that all child_cleanup functions are async-signal-safe; 
that's probably doable.  Can apr_proc_create just do some "close all fds 
> 3" in the forked child?  I guess it all gets too icky.


View raw message