> From: Ian Holsman [mailto:[EMAIL PROTECTED]] > 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 ?
I think we are getting confused here. There are two points that are completely separate. 1) Threads must be allocated out of a pool to avoid mutex locking. 2) Data must be tied to a pool, but that pool shouldn't be tied to any one specific thread (although only one thread at a time can own and use the pool). Those two conditions are not mutually exclusive. It is rather easy to have a pool that is tied to each thread, which is used for thread specific information, and another pool which migrates from thread to thread handing off data. Which thread owns the pool at any once instance must be carefully controlled so that all race conditions are avoided however. The point that we are discussing now, is how to kill a thread when it's pool dies. It isn't possible to do so reliably. The thread could very easily be in a state that is non-cancelable, which means that it won't die no matter what you do. The only option is to make the thread responsible for cleaning up its own pool if you want to be sure that one never exists longer than the other. The question now is how to reliably tell a thread to die and clean up the pool. The best option that I have heard so far is to register a function that essentially signals the thread. This would then require that the signaling thread wait for a response from the signaled thread to ensure that it has died correctly. Ryan
