apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Possible race condition in pools WAS: RE: Thoughts on locks
Date Fri, 29 Jun 2001 22:27:02 GMT
On 28 Jun 2001 15:56:06 -0700, Ian Holsman wrote:
> damn meetings... the code is 90% there and lives in:
> 
> http://webperf.org/a2/pool/
> 
> the code is designed to test 'pools' so SMS would have to implement
> the pool function names... (for the first pass of the code anyway)
> 
> ..Ian
> 
> (hoping to complete it tomorrow)
> 

Ok.. the program is now there.. and seems to be working. 
This should be a good way of comparing SMS and the pool code once the
pool->sms code is written.. the sample files being used are from a dump 
of a 'default-handler' and a include filter. (the include createas about
~34 pools .. compared to the '3' of the flat file no wonder its slow)

..ian
> 
> 
> 
> On 28 Jun 2001 08:51:00 -0700, Justin Erenkrantz wrote:
> > 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
> 



Mime
View raw message