> 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
