apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: mem locking (was: Re: cvs commit: apr/memory/unix apr_sms.c)
Date Mon, 11 Jun 2001 15:43:10 GMT
I can see why it might be useful in shared memory, so if it can be worked
into any shared sms's then fine (I can see a number of ways of doing it
there, but all are messy) but it's not something we need to add to the
general purpose sms's, IMHO.

It can be added to the individual sms's header file with no trouble.
Optional support isn't worth the hassle right now and I can't really imagine
it'll be needed.

david


> 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