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?'' Bill
