David Reid wrote:

>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.
>
I like the concept of registering threads' "interest" in an sms.  But how do
you handle the need for synchronization in a parent sms?  E.g., if an app
creates an global sms and then two different threads create sms_block
instances with the first sms as their parent, the two child sms_block
instances don't need to do any locking but the parent sms does.  A
reference count isn't sufficient to determine whether locking is needed
in the parent; it really needs to know the number of distinct thread
IDs registered with its children.

--Brian