apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <s.stri...@striker.nl>
Subject Re: Changing the order of cleanup for some core objects
Date Tue, 22 Jul 2008 07:12:50 GMT
On Tue, Jul 22, 2008 at 8:52 AM, Bojan Smojver <bojan@rexursive.com> wrote:
> On Tue, 2008-07-22 at 08:42 +0200, Mladen Turk wrote:
>
>> In the original pool_destroy the pool->sibling access is guarded
>> by mutex. Since in multithreaded environment child pool might be in
>> the middle of destroy process detaching himself, think you'll have
>> to guard the access to pool->sibling in destroy_safe as well
>>
>> Also there is a problem if the root pool gets destroyed in which case
>> you'll be accessing zombie memory, so I don't think this will help.
>
> Yeah, I was afraid you may say something like this :-(
>
> Never mind, it was just a random idea (I didn't find it particularly
> good either).
>
>> Guarding that externally would make things basically single
>> threaded and that would be performance killer.
>
> If we were to go single threaded for pools (i.e. global pool mutex), the
> solution is easy: have a hash of all pool pointers and look in there
> before whacking any pools. Along the lines of my incorrect "volatile"
> approach, but with zero API change. But I'm sure that isn't going to
> fly, because pools need to be fast and multi-threaded.

Note that pools are specifically *not* thread safe.  Only one thread
can 'own' a pool at a time, and when there are subpools on another
thread, you'd better protect those subpools from not being destroyed
while that thread is running.  Hence me saying that cases where the
root pool is being destroyed is moot.

Cheers,

Sander

Mime
View raw message