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 ? ..Ian > > Bill >
