apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 17:18:56 GMT
> On Thu, Jun 28, 2001 at 08:28:41AM -0700, Ian Holsman wrote:
> > I'm in the middle of writing a pool-tester
> > which can take a file and pool allocation commands
> > (alloc/create/destroy/etc)
> > and replay them.
> > combine this with some threads, and a capture tool in the current pool
> > code and we should be able to test different pooling algorithms easily.
> >
> > (should be done today)
> Yea, please post when you are done!  My gut feeling is that threaded APR
> is just awful at pool allocation right now.  =)  If we use SMS, it'd be
> nice to have some way of knowing whether we are faster than what we
> have now.  Baselines (no matter how sucky) are good to have before
> embarking on such a change.  I wonder how the SMS stuff will mix with a
> prefork MPM - which never needed locking in the first place.  Be worth
> checking out.  -- justin

We are currently working on a way to do 'locking on demand'. Possibly I
have some more time next week to work on that.

In a single thread, performance between a pool like sms and pools is
almost the same. It varies between +5% and -5% *). However, with a variety
of choice between smss you should be able to choose a 'best performing'
sms for a certain situation (ie. if you know you only are going to
allocate blocks of the same size, use sms_blocks).


*) On my machine (linux 2.4.3, glibc 2.2.2, gcc, using

View raw message