sms locking revisited (was: [STATUS] (apr) Wed Jul 18 23:45:12 EDT 2001)

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

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