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 >
