Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@samba-tng.org>
To: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
Cc: <dev@apr.apache.org>
Subject: RE: cvs commit: apr/memory/unix apr_sms.c
Date: Mon, 11 Jun 2001 01:26:09 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOAEPGDPAA.striker@samba-tng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010611003153.D2726@angua.rince.de>
Importance: Normal

[...]
> > 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