httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: Management of thread pools
Date Mon, 14 Jun 1999 15:36:22 GMT

This idea of having a dynamic thread-pool still seems like a bad idea to
me.  I have no problem if it can be done well, but I don't think Unix
threads are up to that task yet.

When we first started this project, we had one thread which started all
the other threads, and then went away.  We did this, because it made
signal handling MUCH easier (It removed all of the signal hadnling holes,
we still have at least one).  This thread_starter thread was taken out of
the server, because while it was in the server we had a HUGE leak of some
sort.  I believe that the problem was if the thread_starter thread was
used, it was possible that our server process would start to chew up 10
Megs of memory.

This unexplained 10 Meg problem was never actually nailed down and fixed,
but removing the thread_starter thread has made the problem go away.  Now,
I don't know if there was a bug in the Apache code, or the thread library
code.  What I do know, is that there was a bug somewhere.

We should not be investing great amounts of time in this, if having a
dynamic thread pool, is going to cause big problems in the future.  I
will also note that the thread_starter thread used to take care of
exiting by itself, it was not canceled.  And this problem was only seen to
the best of my knowledge on Linux.

I may be very wrong about this, and I haven't done any digging around in
that code to find the bug, but it really seems like the obvious place to
start before we try to do the same thing again.  :)

Just MHO,

Ryan


On Fri, 11 Jun 1999, Manoj Kasichainula wrote:

> There are a few ways I can think of so far if we want to allow each
> child in the hybrid server to create and destroy threads on the fly:
> 
> 1. Use the existing server-wide child shutdown pipe to also send
> thread-create/thread-destroy messages. This will keep the level of
> infrastrucuture in parent-child communication down, but for the
> SINGLE_LISTEN_UNSERIALIZED_ACCEPT case, every message on this pipe
> wakes up every thread.
> 
> 2. Create a pipe from the parent to each child. This will give
> us fine control of how many threads each child had, but it is an
> added pipe that has to be watched by each process, and (this is an
> incredibly minor thing) we've limited our number of children to the
> number of file descriptors allowed per-process.
> 
> 3. Let each child manage its own thread pool, based on how busy it is,
> without any guidance from the parent . This appeals to me, but I
> shudder at what the behavior of the server might be with this change.
> 
> -- 
> Manoj Kasichainula - manojk@raleigh.ibm.com
> IBM, Apache Development
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message