apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: Pools rewrite [2]
Date Wed, 05 Dec 2001 03:19:53 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




Mime
View raw message