apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Review of possible replacement for pools
Date Sat, 25 Aug 2001 17:29:08 GMT
On Sat, Aug 25, 2001 at 01:45:21PM +0200, Sander Striker wrote:
> This _is_ a race condition.  I reported this at the end of june on list.
> Subject: Possible race condition in pools WAS: RE: Thoughts on locks.
> At the end of the thread the conclusion was to fix it, most likely
> through documentation.
> 
> Personally I think that locking on each allocation will kill performance.
> Just never use a pool in two threads.

Yeah, I vaguely remember that thread.

You can certainly use a pool in two threads.  If we add an option when
creating a pool to indicate that it isn't shared, the performance 
isn't a factor.  But, allowing this race condition is going to trounce 
somebody at sometime.  The likelihood of having the context switch
happening here is low, but it is possible.

I'm not exactly sure how to fix it in the current pool code without
killing everyone.  With your version, you can do it via an option to 
apr_pool_create_ex.  So, I don't think we'd end up losing that much
performance if we use the option in the right places.  -- justin


Mime
View raw message