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 15:00:55 GMT
On Mon, Jun 11, 2001 at 10:04:09AM -0400, Bill Stoddard wrote:
> 
> > > This thread is getting rather long, but I don't see the motivation.
> > >
> > > What is the requirement for this range locking? 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?
> > >
> > > I'm not seeing it.
> > 
> > Me neither.  It'll be a PITA to implement and not worth our while IMHO.
> > 
> > david
> > 
> > 
> 
> I agree

having read ben's message [regarding emulation of range_lock() if
it is not supported], i agree that emulating range locking is
tricky, and may even ... *thinks* ... be unworkeable.  i dunno.
have to think about it.  which means it's going to be tricky.
which means complex.  which means complex code to maintain,
which means nightmare, don't do it with big alarm bells.

given this, david, bill, others, having optional support for
sms->range_lock() in sms that [sms] Users have to detect and
cater for if it they want or need it [for speed/optimising
purposes], or just use sms->global_lock() if they can't
be bothered:

is _that_ an acceptable thing to do?

not too complex, etc.

lukes

Mime
View raw message