On 9/8/06, Joe Orton <[EMAIL PROTECTED]> 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.
