apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jwool...@apache.org
Subject cvs commit: apr STATUS
Date Thu, 11 Jul 2002 23:00:54 GMT
jwoolley    2002/07/11 16:00:54

  Modified:    .        STATUS
  This seems to be a fairly moot issue at this point.
  Revision  Changes    Path
  1.141     +1 -50     apr/STATUS
  Index: STATUS
  RCS file: /home/cvs/apr/STATUS,v
  retrieving revision 1.140
  retrieving revision 1.141
  diff -u -d -u -r1.140 -r1.141
  --- STATUS	11 Jul 2002 23:00:17 -0000	1.140
  +++ STATUS	11 Jul 2002 23:00:54 -0000	1.141
  @@ -79,55 +79,6 @@
            -0: wrowe, jerenkrantz, striker
            -0.5: rbb
  -    * For the atomics code to be efficient it depends on instructions
  -      in newer sparc models. Unfortunately this means that binaries
  -      optimized at build-time for these architectures will not work
  -      on older hardware, regardless of the version of Solaris running.
  -      The same is likely happening on the various x86 implementations.
  -      Although I had high hopes for the atomics code, I think we can
  -      not support it in a way that is compatible with the portability
  -      goals of APR, and I hereby propose that we remove it from APR.
  -      +1: Aaron
  -      -0: Justin (I think it's warranted and fits with our portability
  -                  goals, but I'm not going to spend my time supporting it -
  -                  although I have spent more time on this than I'd like.
  -                  If someone wants to maintain it, more power to them.  If
  -                  no one maintains it, this gets changed to a +1.),
  -          BrianP,cliff,gregames:
  -	  	  (All the reasons why we don't want the processor-specific
  -                  code in APR are also reasons why I don't want to push
  -                  that code up into the apps that use APR.  I'd rather
  -                  spend some more time searching for a workable solution
  -                  before we give up on atomics.  Perhaps we should let
  -                  apps using the atomic API set a preprocessor flag to
  -                  choose an "optimal" or "portable" version of the atomic
  -                  ops?)
  -          Sander (The positive sides of the atomics outweigh the negative
  -                  in my opinion.  That said, I am not going to be the
  -                  one spending time on this, since asm on various
  -                  processors isn't really my game)
  -          Jim,rbb:
  -	  	  (who thinks we'll need to reformat this vote) Any time
  -                  you make use of processor specific code for optimizations
  -                  or capability, you run into portability concerns. The
  -                  real option is to make atomics a compile-time option.
  -                  YES means you use the atomics code, based on the *build*
  -                  machine (and therefore carries some dependencies) or
  -                  NO which maintains "universal" portabiity, which is
  -                  what we have (but the default being NO atomics)
  -      -1: IanH, BillS: 
  -                  I don't agree. I think APR is the perfect place this kind of thing. 
  -                  For platforms that support it is a big win, for ones which don't
  -                  they are no worse off than the alternative.
  -                  I can't maintain every asm implementation, but I am volunteering
  -                  for sparc/x86.  (we could also grab the FreeBSD 
  -                  implementations for HW they support)
  -                  Unfortunatly I was out of action for a month when half the 
  -                  hubub was going on. 
  -                  The other alternative for non-native support is maybe to turn 
  -                  it into a spin lock

View raw message