apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 17:17:59 GMT
OK, well I'll try to add some stuff to this discussion...

Last night I tried to get sms looking and acting as pools  Basically I added
some stuff and munged my tree so that when apr_pool calls were made they
were answered in sms code.  This is configurable via an --enable-sms switch
to configure.  The default is just to build the existing pools code.  To
keep all the portability I may do some more but it'd be nice to have a
situation where we can have pools being either the pool code with sms
alongside as just sms, or pools as sms with sms alongside.  This should mean
that anyone using sms isn't stopped and we can develop using sms as pools...

It took me about an hour to make the chnages and get it all building, 30
minutes to find and fix a few bugs but then it would run all the tests.  So
far I haven't added all the functions needed so couldn't get an apache build
using it, though that thought did scare me a little!!! :)

Now, I know there has been a lot of talk about this, but I still think this
is the way to go, however, please speak if you disagree (Roy can you start
using email rather than baseball bats :)) Thanks)

For locking (wow, back on topic) Sander has an idea whereby we register a
threads "interest" in a sms when it's created.  This is simply done via a
counter, so if we have a counter <= 1 then we have no threading issues so we
ignore all locking (prefork), otherwise we lock.  This has some nice
advantages.  Think of an sms/pool that is onyl ever used in a single thread
(connection pool in a threaded MPM).  without doing anything special we
simply don't ever lock.  This seems like the best solution I've seen so far
for our varied requirements.  It also seems the cleanest.

The main thing about this is that we either have to register the thread via
a specific call (miss one and we're in trouble) or we do it the thread/sms
code for apr, which makes sense but would work best is we had pools == sms
(in whatever guise we end up with).

Once I have a patch I'll post it here and let you all see what's involved.
It'll probably be over the weekend whilst I'm on my way to/from Boston.

BTW, if anyone is in Boston on Saturday maybe we could arrange to meet up?
Ben L is there and Ben H lives there so hopefully I'll be seeing them.

david

> 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