On Thursday, August 7, 2003, at 04:44 PM, William A. Rowe, Jr. wrote:
If this is a serious consideration - perhaps we have a problem with our implementation.
That's why the atomic stuff is optional. You can chose to make your binaries incompatible if you so wish.
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.
The problem isn't that we'll chose the wrong implementation at run
time, it's that the same binary that runs on one Solaris box won't necessarily
run on another box, even if the other box has an equivalent or newer version
of Solaris.
But I thought this was specific to our atomic/solaris/ implementation which has disappeared (due to licensing, iirc?)
I don't think it was solved, but I had a terrible memory for these things.
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?''
That is true. Also it is true that we have another couple of ways to solve this:
1) Remove nested locks. Who's really using them anyway!? 2) Create a secondary internal mutex only when we need nested mutexes, and use that mutex to protect all accesses to the mutex->owner and mutex->owner_ref variables.
-aaron
