apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr configure.in
Date Wed, 01 May 2002 17:56:10 GMT
On Tue, Apr 30, 2002 at 11:49:41PM -0000, Justin Erenkrantz wrote:
> jerenkrantz    02/04/30 16:49:41
> 
>   Modified:    .        configure.in
>   Log:
>   Add --disable-atomics flag which will prevent APR from using its *own*
>   optimized code.  On those OSes that properly support atomics from userspace,
>   we will use those no matter what the user specifies.  Therefore, this change
>   only affects Solaris/Sparc - if --disable-atomics is passed, we will use
>   APR's generic code.

Since this doesn't really disable the atomics, please rename
it. Something like --disable-optimized-atomics, or how about
--enable-nonportable-atomics.


I'd like to continue the discussion about non-portable binaries. Although
I think it would be great if APR could handle atomics, I don't see that
happening. Here are a couple problems that I see:

1) non-portable binaries:
   By default any binaries built on solaris 5.6/sparc will not run on
   older architectures, even when Sun supports newer operating systems
   on those architectures. (eg. 5.6 binaries don't work on some 5.7/5.8
   machines.)

2) inefficient portable binaries:
   The whole point of the atomics code isn't just to do atomic
   operations, but to do them efficiently. Mutexes already give us
   atomic operations. If you specify the above flag, any part of your
   application that depends on efficient atomic operations will be making
   a false assumption. Since APR is not satisfying a requirement of the
   application, APR is not supporting atomics on that platform.

I don't think it is APRs job to choose efficiency over portability, even
at the binary executable level.

-aaron

Mime
View raw message