httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [PATCH] Problems with MPM threaded
Date Sat, 14 Jul 2001 16:19:17 GMT

> > SOLUTION 2: One could use a slightly more _involved_ approach, where the
> > dying thread could send a signal to its sibling threads, each of which will
> > then handle that signal with a graceful exit.
>
> How?  A thread doesn't have a process id associated with it.  And, I'm
> curious to whether the signal would somehow kick us out of the acquire
> function.  Doubtful.  I may be wrong (probably am).  Please correct me.
> We need to be able to tell the threads they need to exit, but you can't
> force them to just exit (which is why pthread_cancel wouldn't work).
> They need to exit on their own - otherwise, they won't cleanup.
>
> > SOLUTION 3: We could turn our heads the other way by not worrying about this
> > situation at all, since these threads would eventually die (when more
> > requests are handled by the webserver).  However, by ignoring the problem,
> > the purpose of perform_idle_server_maintenance() would be lost!!
>
> And, based on my interpretation and analysis of the threaded MPM and its
> intentions, we shouldn't even need to worry about this case.  Let me
> explain:
>
> The problem you are stating is that the POD is received by one thread in
> one child process, it marks workers_may_exit and then quits.  The accept
> mutex is then shifted over to another child process which doesn't have
> workers_may_exit set and goes on its merry way.  The only time we check
> for workers_may_exit is after the mutex has been acquired.  Therefore,
> it can take a while to have all of the threads in that POD-receiving
> process to see workers_may_exit.
>
> Threaded MPM is designed (rather should be - the implementation
> doesn't suggest this) to only have ONE child process that does the

No!  The threaded MPM does NOT and was not intended to implement a
thread-only server.  It was designed to implement a hybrid thread/process
server.  Because we expect both threads and processes, the rest of this
message is based on a misconception.  Having multiple processes each with
multiple threads provides for FAR more robustness than just a single
process with multiple threads.  If you want that, then you want the
perchild MPM, so that the number of threads can grow and shrink correctly.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message