On 8/31/05, Colm MacCarthaigh <[EMAIL PROTECTED]> 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. 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. What about mutexes? Does the forked, held mutex get released automatically by the new child when it does exec()? Does it depend on which type of mutex? Is APR going to have to use atfork handlers to clean up its own mutexes to prepare for this scenario? (which wouldn't help the typical commercial third-party module which has its own portability layer to support deployment in Apache, IIS, SunOne, etc.) (I keep the idea of a fork service in the back of my mind, which generalizes the daemon feature of mod_cgid for use by any Apache modules which need to create child processes from MPM threads.)
