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
