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 http://www.novell.com >>> Brian Pane <[EMAIL PROTECTED]> 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 object. 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? Thanks, Brian
