apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Review of possible replacement for pools
Date Sat, 25 Aug 2001 18:05:03 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.

Agreed.

> 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

Adding an option to apr_pool_create_ex to indicate that the pool is
going to be shared across threads would be an option I can certainly
live with.  OTOH, this will introduce an extra if(lock) pair in the
apr_palloc and apr_pcalloc calls.  I'll send in a patch later on.

I didn't implement apr_prealloc yet, but would like to know if people
would find it usefull.  If so, I will post a patch.

Sander


Mime
View raw message