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