[...] > > And if the locking mechanism doesn't support regions? (This is > > particularly important if you allow unlocking of subregions). The > > obvious answer being that we implement them in APR, of course. > > well, that is what made me think that perhaps a separate > lock and lock_region be done, such that one or other > cold be supported. > > 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. > > .... ?
About the apr_sms_get_features() suggestion: It is the programmers job to find out _in advance_ if the type of sms he is going to use will support what he needs. Selecting a non locking sms in a multithreaded piece of code would be wrong, for example :-) > luke Sander
