apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: problem with apr_atomic_init on freebsd
Date Fri, 05 Jul 2002 21:05:41 GMT
On Fri, 2002-07-05 at 14:00, Garrett Rooney wrote:
> 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...

Here's what I have so far. It's basically the same as what
you've described, except that I have an additional check to
make sure the apr_atomic_init() isn't already defined as a
macro.

Does this work on FreeBSD?

--Brian



Mime
View raw message