apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/locks/unix thread_mutex.c
Date Thu, 07 Aug 2003 23:44:31 GMT
At 05:43 PM 8/7/2003, Aaron Bannert wrote:
>Won't this introduce a binary dependency on the implementation
>of the atomics? What I mean is before, code that used the atomics
>was restricted in some cases (solaris) on the same type of underlying
>hardware, and could no longer rely on the version of the OS to
>determine binary compatibility. Now we're extending that requirement
>to any code that uses thread mutexes. Can we come up with another
>solution that doesn't introduce the dependency?

If this is a serious consideration - perhaps we have a problem with our
implementation.  Note that the actual atomic logic (be it a macro around
specific system calls, or some apache-internal implementation, or 
devolves to specialized assembly code) will be self-contained within
the libapr.so/libapr.a, it isn't something that affects the actual binary
linked into libapr.

But I thought this was specific to our atomic/solaris/ implementation
which has disappeared (due to licensing, iirc?)

I wouldn't make this a consideration of the threads library, if we have
problems with apr_atomic.h that make us unhappy, we should address
that rather than worrying about 'should we use our own API?''


View raw message