apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Pools rewrite [2]
Date Wed, 05 Dec 2001 03:53:28 GMT

> Cliff Woolley wrote:
> >>This is my second go at the pools code.
> >>
> >
> >A potential snag with the thread-specific pools idea was brought up today
> >when I was talking with FirstBill and some of the others.  What is this
> >going to do to us a little ways down the road when we try to implement
> >async I/O, and all of the sudden requests are jumping from one thread to
> >another?  Sounds like a big problem if thread-specific pools are in
> >place... is there an easy answer?
> >
> I think there's an easy answer.
> The thread-specific pools in this implementation are really
> just pools that happen to own their own free lists.  If those
> pools get moved from one thread to another, that's okay, as
> long as only one thread at a time is accessing a given pool
> (which has always been a restriction of the pool API, because
> apr_palloc() isn't thread-safe).  In fact, we have this scenario
> already in the worker MPM with Sander's pool code: the
> thread-specific pool for each request gets created by the
> listener thread and handed off to a worker thread.
> If a future async implementation has this same property--i.e.,
> pools can be "passed" from one thread to another, but a given
> pool can only have its methods invoked from one thread at a
> time--then we shouldn't have any problems.
> --Brian

What happens if a thread exits (under shutdown for instance) and requests are still being
handled by other threads asynchrounously? Looks as if that threads cleanup will free the
pool out from under the thread using the pool at the time.


View raw message