apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: apr_pools and thread safety
Date Thu, 30 Jun 2005 06:16:53 GMT
E Holyat wrote:
> What if one thread destroys the allocator while this function is trying 
> to dereference it.

That means you have lifetime issues and that is considered a bug in your
application.  You should make sure the allocator lives longer than the
pools allocating out of it.

> No matter what, you are going to lock in 99% of the time,

The number is probably high, but I don't know how high.

> why not be safe and lock it before dereferencing it.

At the time I tried to make sure we never took out the mutex when not
99% sure we were going to use it, due to performance reasons.

> Besides if you are going to fall into an if and wait on a mutex, 
> shouldn't you check the if statement again too?  What is the purpose of 
> the if statement when by the time a thread acquires the mutex, the if 
> statement may no longer evaluate to TRUE?

The if statement doens't need to be reevaluated because the code that
is executed contains the same conditions as the if statement.  It may
not directly be obvious, since the code is fairly dense, but this should
and AFAIK is, the case.

The important part is that there is no race condition leading to your
NULL bug.  Do you agree that so far there is none?


View raw message