httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: [Win32] Current CVS crashes on shutdown
Date Tue, 19 Mar 2002 16:41:53 GMT
Bill Stoddard wrote:
>>On Tue, Mar 19, 2002 at 06:49:28AM -0800, Ryan Bloom wrote:
>>>>To protect against that we either need thread cancellation, and
>>>>register a cleanup with pool B that will cancel the thread if
>>>>the pool is destroyed.  Or, we need other means of protection
>>>>against double destruction (refcounting of pool users(threads)
>>>>comes to mind).
>>>The only way I see to do this is to make destruction of a thread's pool
>>>kill the thread.  Of course, that isn't easy to do, because the thread
>>>could be in a non-cancelable state.  The only other option is to kill
>>>the cleanup in the thread-exit code if you have already cleared the
>>>pool.  I am not sure how easy or hard that would be do to though.
>>I've always been of the opinion that we shouldn't be forcing threads to
>>be tied to threads. My prefered thread API is not pool aware, leaving
>>the app author to create and pass subpools through the opaque data to
>>the thread and manage their own scope or explicit destruction.
> I agree... threads and pools should not be tied together. In the future, we want to be
> able to make Apache 2 do event driven network i/o which means that one thread might
> initiate and i/o and another thread completes the i/o. A single HTTP request/response
> transaction might be touched by many threads and we do not want the storage for the
> transaction to be tied in any way to any one thread.

The thread/pool tie in was done so we could remove the single free-list 
bottleneck. which meant a mutex around every allocation.

do you have any ideas on how keep multiple free-lists and not tie it in
to the thread ?


> Bill

View raw message