apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: API to prevent further allocations from a pool?
Date Fri, 08 Sep 2006 12:09:35 GMT
On 9/8/06, Joe Orton <jorton@redhat.com> wrote:

> But to make a strong API guarantee I think this would need to use atomic
> operations anyway, which means the performance hit (mutexes on some
> platforms) would indeed be way too high for the pool allocation critical
> path, I think.

I don't see the need for thread-safety here, though perhaps we're
thinking of two different things.  (apr_pool_freeze() may be a better
name for what I'm thinking of.)

The freeze operation doesn't have to be thread-safe because pools
themselves aren't thread-safe.  (If there are multiple threads
modifying the pool before freezing the app is already broken.)

The unfreeze operation doesn't have to be thread-safe because an
unfrozen pool isn't thread-safe (i.e., if multiple threads are
modifying the pool after unfreezing then the app is already broken),
and by unfreezing the pool in a multithreaded environment the app
loses the guarantee possible with a frozen pool.

Mime
View raw message