> > > or, you mandate providing locking, emulating regions by > > > ... errr.... providing ref-counting on a global lock (yuck!) > > > > > > hm, that don't work. nope: have to do the lock and > > > lock_region, then have a means for Users to detect > > > that a lock_region function is available / supported. > > > > > > you know, this is all tending to suggest having a > > > 'apr_sms_get_features()' fn, returning a bitfield > > > of supported features. > > > > You can emulate regions with global locks and shared memory, of course. > > And still tell people which you support natively. > > > > Don't know whether its worth it - does anyone have any views?
hiya ben, well... yes, i do: i wouldn't recommend making anything such as emulation of range locking 'mandatory' in sms. it's quite complex, i guarantee you: see samba's emulation of NT byte-locking on top of posix range locks! given that... okay, it's a long story. trust me: you don't ever want to try it :) :) anyway - the point of sms is KISS. to the extent that we're having quite complex discussions right now, as experienced experts and developers, to stave off and help justify _not_ adding in complexity. the fine line between simplicity/complexity and necessary/nice-to-have _can_ be walked :) so, my recommendation is, make range_locking() either non-existent [favoured by some because i didn't mention a justification for adding it, *duuh* :)] or optional. i mean, to be honest, the number of smses that are likely to _use_ range_locking() is probably going to be quite small, although i can't speak for the people whose job it is to worry about speedspeedspeedoptimiseoptimiseoptimise in apr/httpd, esp. in the area memory handling :) i only recommend range_locking() as a possible way to provide that speedoptimising if it's thought necessary. otherwise, it doesn't bother me particularly if it's not added. all best ben, luke
