Okay, but this is the scenario that I do want (one worker, many threads)
... so I setup my httpd.conf as:
<IfModule worker.c>
StartServers 1
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
But as soon as I start up, it starts 3 servers (I would expect 2 ... one
root, one nobody):
atelier# ps aux | grep http
root 59418 0.0 0.1 1416 1052 ph RV+ 1:41PM 0:00.00 grep http (csh)
root 59405 0.0 0.4 5316 3708 ?? Ss 1:39PM 0:00.03 /usr/local/sbin/httpd
www 59406 0.0 0.3 5096 3480 ?? I 1:39PM 0:00.00 /usr/local/sbin/httpd
www 59409 0.0 0.4 7420 4000 ?? I 1:39PM 0:00.00 /usr/local/sbin/httpd
With the second one be a good 50% larger then the other two ...
So, am I mis-understanding below, *or*, mis-understanding the conf file
...
On Tue, 21 May 2002, Aaron Bannert wrote:
> On Tue, May 21, 2002 at 01:14:00PM -0300, Marc G. Fournier wrote:
> > Just to confirm, would it be the following that I'm looking at:
> ...
>
> Nope, further down:
>
> * FreeBSD, threads, and worker MPM. All seems to work fine
> if you only have one worker process with many threads. Add
> a second worker process and the accept lock seems to be
> lost. This might be an APR issue with how it deals with
> the child_init hook (i.e. the fcntl lock needs to be resynced).
> More examination and analysis is required.
> Status: This has also been reported on Cygwin.
> Message-ID: <[EMAIL PROTECTED]> (cygnus)
>
> Justin says: So, FreeBSD-CURRENT and Cywin have the same
> problem. Yum. If another platform has this
> with worker, this becomes a showstopper.
> Aaron says: I spent some time disecting this and have come to
> the conclusion that it is not a problem in the worker MPM
> (or at least, it is not isolated to a problem in worker).
> I'll list some of the problems I'm seeing in case someone
> else wants to pick up where I've left off:
> - Delivery of just about any signal to one of the child
> processes will send it into an infinite loop as well.
> - Even though the parent is spinning out of control,
> at first the child or children will appear to work
> properly. At times it is possible to get it into a state,
> however, where a request will hang until another concurrent
> request "kicks" the first, at which point the second will
> hang. My theory is that this has to do with the
> pthread_cond_*() implementation in FreeBSD, but it's still
> possible that it is in APR.
>
> Justin adds: Oh, FreeBSD threads are implemented entirely with
> select()/poll()/longjmp(). Welcome to the nightmare.
> So, that means a ktrace output also has the thread
> scheduling internals in it (since it is all the same to
> the kernel). Which makes it hard to distinguish between
> our select() calls and their select() calls.
> *bangs head on wall repeatedly* But, some of the libc_r
> files have a DBG_MSG #define. This is moderately helpful
> when used with -DNO_DETACH. The kernel scheduler isn't
> waking up the threads on a select(). Yum. And, I bet
> those decrementing select calls have to do with the
> scheduler. Time to brush up on our OS fundamentals.
>
> -aaron
>
