Sander Striker
Tue, 22 Jul 2008 00:13:24 -0700
On Tue, Jul 22, 2008 at 8:52 AM, Bojan Smojver <[EMAIL PROTECTED]> 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