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: mem locking (was: Re: cvs commit: apr/memory/unix apr_sms.c)
Date Mon, 11 Jun 2001 14:27:51 GMT
On Mon, Jun 11, 2001 at 11:45:07AM +0100, David Reid wrote:
> > This thread is getting rather long, but I don't see the motivation.
> >
> > What is the requirement for this range locking? 

multiple threads accessing same memory range.

see tdb for the motivation.

tdb is gdbm-like simultaneous reader, simultaneous WRITER
[unlike all of the other *dbm databases, which have funny things
like, if you write to this db, all bets are off.  ??? :)]
db-access, with optional mmap support.

the implementation for the data-access is hash-chains.
each hash-chain is *individually* locked, with a byte-range
posix lock.

they have some intriguing double-dealing with enumeration,
and are not recommending the use of the first/next as a result,
but recommend using the tdb_traverse() instead.

anyway.  if an sms-implementor of an mmap or thread-accessed
memory module decided to optimise it by having the admin-memory
byte-range-locked, that should be their choice to be able
to do that.

by not providing an sms->range_lock() fn, or equiv., that
optimisation possibility is pretty much guaranteed ruled out.

in a stackeable manner, anyway.

> We don't have to do
> > everything imaginable simply because we can. Every time we load "features"
> > into APR(UTIL), that just means we need to maintain them. Why do we *need*
> > this feature? And will it be widely useful?

do you think that allowing [sms] Developers to optimise
memory-administrative management is good?

and if so, does that help justify providing range locking
in sms? 

> > I'm not seeing it.

that's because i didn't explain/justify why i was recommending it.

which would help :)


View raw message