On 7/17/06, Branko Èibej <brane@xbc.nu> wrote:
> Garrett Rooney wrote:
> > On 7/17/06, Branko Èibej <brane@xbc.nu> wrote:
> >
> >> Oh bother. I must have been smoking something really weird to not notice
> >> the this would obviously happen.
> >
> > Don't feel so bad, I should have seen it to...
> >
> >> Back to the salt mines it is, then ... I think that commit was quite the
> >> wrong solution, I'll have to come up with something better. Sheeh, but
> >> pools really are a total lossage in the presence of global caches.
> >
> > Here's a fix that appears to work. It makes it so that we NULL out
> > the lock when we clear its pool, and then only try and lock it if it's
> > non-NULL. This fixes the weird issues Mike was seeing, and should fix
> > the valgrind problems, although I haven't actually confirmed that.
> Assuming apr_terminate runs in a single-threaded context (which it
> should), this certainly seems to plug a hole. I can't be sure right now
> if it's the _only_ hole, but +1 to commit this in any case.
I believe we already assume that in other parts of this code... Or at
least some version of it did, I recall seeing a comment justifying
something based on the fact that either we had already locked the
appropriate mutex or we were in single threaded mode during atexit
handling.
Anyway, will commit and propose for backport.
-garrett
Received on Tue Jul 18 02:56:33 2006