apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: apr_memory_system.c;apr_memory_system.h
Date Tue, 08 May 2001 15:24:51 GMT
On Mon, May 07, 2001 at 08:43:02PM +0200, Sander Striker wrote:
> documentation in the code should be clear enough,
> but there are a few issues that Luke would like to
> add (regarding locking). Luke, please state them
> here and I'm sure someone will copy them over in
> the final source.

memory contention (blocking signals, locking of mmap'ed
files etc.) must be handled transparently by an implementor
of an apr_memsys.

i.e. the implementor must, for example, if implementing a
mmap'd apr_memsys, when a block is requested, must lock
the relevant mmap'd section(s) - see tdb.c which lives
on sourceforge.net/projects/tdb for a clear example - 
modify all management linked lists, unlock relevant

sander, it occurs to me that this may actually have to
be exposed up to the users of a memory block, in some
way, for exactly the same reasons that tdb has tdb_lock()
and tdb_unlock().

you wish to perform some transaction on the memory, but
it is up to the implementor of the apr_memsys to hide the
details of the locking required from the users of that

i don't just mean for accounting / management, i mean
for actual usage.

we cannot assume that some locking (blocking signals)
which would be suitable for system-memory when accessed
by threads would be suitable when another apr_memsys
is used, by the same code.

so, we really do need to provide apr_memsys_lock()
and unlock.

i would recommend that it take three arguments, like so:

apr_memsys_lock(apr_memsys_t, void *mem, size_t start, size_t end);

with a comment saying that if the void *mem is NULL,
this means 'perform a global, or "management"-suitable, lock'.

yuck, but there y'go.

also, implementors of an apr_memsys may optionally ignore the
mem, start and end arguments, and simply implement apr_memsys_lock()
as a global lock.

... would that cause problems?  because if it might,
it's best to say _now_ :)  e.g. perform two locks on two
separate locations, expecting them to both work, and
you have deadlock - even in a single process.


with optional support for lock_region().


View raw message