On Wed, Jul 18, 2001 at 11:45:12PM -0400, Rodent of Unusual Size wrote: > APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*- > Last modified at [$Date: 2001/07/17 05:43:53 $] > > APR Stackable Memory Code > ========================= > > This is just a small list of things yet to be done, or things > that we may want/need to consider. > > - add a shared memory module. > > - locking needs to be addressed. The scope of the locks needs > to be defined and it's likely we'll need some way of > varying the scope when locking.
just a reminder [yes, i'm being stubborn and stupid, here.] i suggested that the SMS locking api include the means to lock regions [apr_sms_lock(sms, void *area, size_t size) where area=NULL -> global locking and size=0 -> use the entire size of the allocated region you are responsible for. of course, apr_sms_general() or any other non-tracking sms says 'get lost' to this :) ] it was suggested at the time that this locking api was proposed that this should be a 'mandatory' requirement - that _all_ SMS instances must support region locking, by emulating it if the underlying SMS doesn't support it. [i didn't and don't think this is a good idea.] i suggested at the time that it would be better to 'negotiate' an SMS by having a bitfield, such that you can check whether the SMS supports the capabilities you might need: - 'i support region locking' - 'i support global locking' - 'i am threadsafe' - 'i support free' - 'i support realloc' - 'i support destroy' - 'i support mmap' - 'i support mlock' this will actually become quite important for the shared memory module interface. why? because it will be possible to add a 'helper' API to obtain handles to all SMSes that support a particular feature-set, expressed by having an and and a not bitmask pair. luke
