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 05:02:08 GMT
Cliff Woolley wrote:

>Okay.  The situation (real or imagined) I was leery of was not allocation
>but pool destruction... what happens when you have a subpool of a
>one-thread-at-a-time pool that was created in one thread and gets
>destroyed in another pool, if the parent pool is still active in the other
>thread somehow?  I don't have a specific case I can name where this would
>happen, but it seems possible.
>

Fortunately, this scenario doesn't happen in the Apache worker MPM.
The only place where we have a parent-child relationship between pools
in different threads is between the pool in the listener thread and
the transaction pools in each worker.  But the pool in the listener
thread is designated as "shared among threads" so that creation or
deletion of its children always requires locking.

It *is* possible for a hypothetical APR app to have the problem
you've described.  However, consider what has to happen in order
for this problem to occur: The app has to create a pool, designate
it as one-thread-at-a-time, and then create another object (the
subpool) that has the potential to modify the pool at any time (by
detaching itself from the parent pool).  I call that an application
design bug.  The best way I can think of to guard against this is
to put a prominent note in the API documentation that says (in
effect):

    If you're going to declare a pool as one-thread-at-a-time,
    then your application is responsible for ensuring that no
    subpools of this pool can be created or destroyed in other
    threads.

--Brian



Mime
View raw message