Re: Atomic increment/decrement

I still think it could be automatic, but with a runtime test to make 
sure the feature is present. I'm looking into how to do that.

Deborah

On Nov 16, 2004, at 4:36 PM, George Rhoten wrote:

> Hopefully, this e-mail will get through to the icu mailing list.  IBM
> e-mails don't seem to work with the mailing lists today.
>
> I do not agree with this proposal.  ICU should work on older versions 
> of
> an operating system.  We try our very best to allow ICU binaries built 
> on
> a new version of an operating system to work on older operating systems
> too. This is mainly with regards to the core library code.  The test 
> code
> doesn't count.
>
> Some non-core Apple people do distribute ICU binaries to older 
> versions of
> Mac OS X.  Open Office and several other groups would have to know 
> about
> this versioning problem, if this feature was added.  Most people want 
> ICU
> to work, and they don't want to know the details :-/
>
> The default should be to use all functions that are available to all
> recent versions of Darwin, and not the ones that may be occasionally
> there.  This doesn't mean that you can't turn on this feature.  It just
> means that the default is to use the standard way of doing things.
>
> If you want to add something like -DU_USE_MACOSX_ATOMIC_INCREMENT or
> something like that to Apple's build script to enable this in ICU, that
> would be fine to add.  Configure should not be used to detect this
> feature, since you really have to know what you're doing to use this
> feature (I believe this includes you).
>
> So to summarize...  It's okay to add this code to ICU, but it's not 
> okay
> to use it by default.
>
> George Rhoten
> IBM Globalization Center of Competency/ICU  San José, CA, USA
>
>
>
> Deborah Goldsmith <[email protected]>
> Sent by: [email protected]
> 11/16/2004 04:11 PM
>
> To
> icu list <[email protected]>
> cc
>
> Subject
> Atomic increment/decrement
>
>
>
>
>
>
> I'd like to have umutex.c take advantage of built-in atomic
> increment/decrement functions on Darwin. The Darwin-specificity can be
> taken care of by using a U_DARWIN conditional compile. The sticky issue
> is that they are not available on all versions of Darwin (just as ICU
> has new functions added each release).
>
> On top of that, Darwin does not have a global "version of Darwin"
> preprocessor variable defined. So it looks like this will require
> adding something to configure_in to test for the presence of these
> particular functions, or ICU won't compile on a version of Darwin
> lacking these functions.
>
> Beyond that, does there need to be a runtime test, to allow a version
> of ICU built on a version of Darwin that has the functions, to run on a
> version of Darwin that doesn't have the functions? In general ICU
> doesn't seem to go that far in terms of testing for availability: it
> only checks for what's on the system you're building on. Apple doesn't
> particularly have a need for this, either: for us it's OK for a version
> of ICU built on Darwin version A to only run on A or later.
>
> I'd be curious to hear people's thoughts on the best way of doing this.
> I already had a private exchange with Steven about this.
>
> Deborah
>
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>
>