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 sections. 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 apr_memsys. 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. apr_memsys_lock_region(...) apr_memsys_lock_global(.) with optional support for lock_region(). luke
