apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: cvs commit: apr configure.in
Date Wed, 01 May 2002 18:53:19 GMT
On Wed, May 01, 2002 at 10:56:10AM -0700, Aaron Bannert wrote:
> Since this doesn't really disable the atomics, please rename
> it. Something like --disable-optimized-atomics, or how about
> --enable-nonportable-atomics.

No one came up with a patch to do it after lots of discussion about
it.  If you want to rename it, please feel free to do so.  (FWIW,
I'd prefer the first choice.)  As we all know, my naming capabilities
are awful.  Whatever floats your boat.

> 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.)

Hopefully, we can come up with some solution that allows us to
address this.  My first guess would be some type of run-time
morphing of the atomic ops on platforms where we can efficiently
degrade our performance if we're not running on a CPU that supports
our optimizations.  I'm not exactly clear how to do it, but I think
we *might* be able to do this efficiently.  (Perusing the NSPR
sources, it seems that they hinted at doing this, but never did it.)

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

Nope, you are just running on a platform that may not be as efficient.
That's always an assumption that you have to consider.  In fact, I
think we must be optimisitic - what is the *best* conditions that
this code could operate under - rather than the worst condition.
In that case, I think atomics is a good thing to have because on
lots of platforms, this code can be done efficiently without the
overhead of a mutex.

Remember that we're only doing this on platforms that don't expose
a userspace atomic interface.  A bunch of other OSes do this - we've
just run into two OSes that don't.  Shame on them.  But, there is
a way to address this - handcoded assembly.  However, this isn't
something that we're particularly good at.  So, we need to take
time to consider what direction we should take.  Ideally, we
should have had this discussion before the atomics landed, but
oh well.

To me, I guess the more important questions are:

1) Who wants to *use* atomics?
2) Who wants to *support* atomics?

Maybe that's a question we should start out with.  If the answer
is "no one" to either one, it isn't worth our hassle to continue
this conversation and we should remove them.  -- justin

View raw message