apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: problem with apr_atomic_init on freebsd
Date Fri, 05 Jul 2002 21:00:24 GMT
On Fri, Jul 05, 2002 at 01:49:04PM -0700, Brian Pane wrote:
 
> > it's dying because we both #define away apr_atomic_init and declare it
> > (because freebsd defines APR_ATOMIC_NEED_CAS_DEFAULT).
> 
> How about changing atomic/unix/apr_atomic.c so that it defines
> a no-op apr_atomic_init() if threads are disabled?

that works, but you'll have to go get rid of all the places that do a
#define apr_atomic_init APR_SUCCESS, and move the declaration outside
of the #if defined(APR_ATOMIC_NEED_CAS_DEFAULT).

then just add:

#else

apr_status_t apr_atomic_init(apr_pool_t *p)
{
    return APR_SUCCESS;
}
 
right above the #endif /* APR_HAS_THREADS */ in apr_atomic.c.

it means we always get the function call overhead, but really, it's
not like apr_atomic_init is going to be called more than once per
program, so who really cares...

you'll have to be really careful though, since the platform specific
#ifdefs are tricky and i don't think i could get them all right without
having the machines available to test on...

-garrett

-- 
garrett rooney                    Remember, any design flaw you're 
rooneg@electricjellyfish.net      sufficiently snide about becomes  
http://electricjellyfish.net/     a feature.       -- Dan Sugalski

Mime
View raw message