apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: apr_atomic_t: can we change it to apr_uint32_t?
Date Tue, 31 Dec 2002 21:53:06 GMT
  Apache for NetWare only runs on 32-bit architectures.  The only
problem on NetWare is that the NetWare atomic APIs take an unsigned long
and our compiler is very picky about type mismatches.  Defining
apr_atomic_t as  apr_uint32_t throws illegal implicit conversion errors.
 This can be fixed but we would have to make sure and type cast back to
an unsigned long before calling the NetWare API.

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions

>>> Brian Pane <brian.pane@cnet.com> Monday, December 30, 2002 6:32:26
PM >>>
While trying to replace some mutex-based synchronization
code in the httpd with atomic spinloops, I ran into a
problem in the APR atomic API:

With the API split between apr_uint32_t for the CAS
operation and apr_atomic for most of the get/set
operations, it's impossible to use write portable apps
that need to use both CAS and read/write on the same

I think we could fix this problem by forcing apr_atomic_t
to be defined as apr_uint32_t on all platforms.  This would
work fine for the default (mutex-based) atomic implementation,
as well as most platforms for which we currently have custom
code (Linux/x86, Solaris, etc).  The only two I'm not sure
of are:

  Netware:  apr_atomic_t is defined as unsigned long.
  Does Netware run on any architectures where an
  unsigned long isn't 32 bits?

  OS/390:  apr_atomic_t is defined as cs_t.  Can someone
  familiar with that environment please comment on whether
  it would be safe to use a uint32 as the atomic type?


View raw message