httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <stodd...@raleigh.ibm.com>
Subject Re: Pools and Threads and Errors
Date Thu, 14 Jan 1999 17:58:26 GMT
Ben Hyde wrote:
> 

> We have discussed before (a year or more) that every thread ought
> to have it's own pool.  I assume that the pool of a thread will be
> our principle tool for cleaning up when a thread is destroyed.
In a threaded Apache, should the number of threads per process be static
(configurable) or should it vary dynamically based on server load? I
would envision starting a process with n threads. In the pthreads port,
each thread has it's own thread local storage (allocated out of a pool)
that is cleared/reinitialized at the beginning of each new request. The
pool is cleaned up when the process dies. The number of threads per
process remains static.

Here is a related (in my mind at least :-) question... In the NSPR port
and the pthreads port, all the threads block on an accept_loop mutex.
One thread is allowed to call the accept(). When a request comes in, the
thread blocking in the accept processes the request. Apache 1.3 for NT
has a single thread doing an accept(). When a request comes in, queue
element is built an queued to pool of worker threads. Furthermore, each
request thread checks (via calls to WaitForMultipleObjects) to see if
any of the other threads has signaled that it is exiting. Seems the NSPR
and pthread port method is much more efficient model. Why is it
necessary, in the Win32 port, to check for threads exiting?

-- 
Bill Stoddard
stoddard@raleigh.ibm.com

Mime
View raw message