httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
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 Bloom               
Covalent Technologies

View raw message