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
