It seems scary to me to have the MPM parent on Unix forking children while a separate thread in that same process is running arbitrary code. Surprising problems can crop up when this arbitrary code is in certain states (maybe a mutex gets inherited in held state by the new MPM child?)
On Wed, Feb 4, 2009 at 11:09 AM, Mladen Turk <email@example.com>
I would like to commit this module to trunk.
It's a watchdog module that creates a worker threads
either in parent, child via an API, and it's not for
standalone use, but for other module usage like
mod_heartbeat, probably mod_jk and others that need
I once had a rather harsh quote on this topic from Ulrich Drepper taped to my office wall amidst TCP/IP diagrams and definitions of C's break and continue in very large print, but sadly it has gone missing.
However, I just found another one which should suffice:
* Ulrich Drepper <firstname.lastname@example.org> [030910 15:41]:
> Aidan Van Dyk wrote:
> > The particular problem I'm seeing is with syslog_lock.
> The standard doesn't guarantee that any functions but exec works after
> fork in a multi-threaded program.
That doesn't match the profile of an MPM child process ;)