Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Cc: <dev@apr.apache.org>
Subject: RE: Review of possible replacement for pools
Date: Sat, 25 Aug 2001 20:05:03 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOIEBMEHAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010825102908.G17570@ebuilt.com>
Importance: Normal

> 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