RE: [PATCH] Add intraprocess mutex to threaded MPM (WAS Re: Termi niting threads in a process RE: [PATCH] Problems with MPM threaded)

["GUMMALAM,MOHAN (HP-Cupertino,ex2)" <mo...@hp.com>]

Since a lot has happened in the mailing list, since the last time I checked
(on Friday), I am responding only to the questions that still hold
significance, from the original mail I had sent..  Do find my answers
embedded below.

> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Friday, July 13, 2001 11:49 PM
> To: new-httpd@apache.org
> Subject: Re: [PATCH] Problems with MPM threaded
> 
> 
> On Sat, Jul 14, 2001 at 12:42:29AM -0400, GUMMALAM,MOHAN 
> (HP-Cupertino,ex2) wrote:
>
> <snip>
> 
> Have you taken a look at the patch I posted that merges the 
> POD code in threaded with the version in mpm_common.c?  Threaded 
> shouldn't be doing POD checks in threaded.c.  It's redundant and
> it's done incorrectly anyway in the threaded MPM.  
> 
> Admittedly, this doesn't fix the issue of having a child who 
> received a POD kill its sibling threads.  More on that in a sec.

Yes, I did try the patch - as you mention, it did not resolve the problem.
Probably I was missing the right mpm_common.c file, since I had to tinker
around with the code a little to make it work with your patch.  Where can I
find the right one?

> <snip>
> 
> A pthread_cond_wait() and fcntl() are viable options according to the
> manpage.  But, I'd much prefer us to use pthread_mutex_t if at all
> possible for cross-process locking.

pthread_cond_wait() is what I was thinking of - I am still not convinced
that it is a bad alternative (it does use pthread_mutex_t).  I would try to
make it as clean as possible.  Lets see how it pans out.

The current patch that you have posted is good, in the sense that it will
work.  It has one problem though: At any given time, there are only 5 worker
threads (one from each child process), waiting to grab accept_mutex - others
are waiting for their per-process worker_accept_mutex.  Also, each thread
would have to grab two locks, instead of one.  I am sure there would be a
noticeable performance hit at peak loads.  Any comments?

M