On 2013/01/16 03:45, John Baldwin wrote: > On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote: >> On 14 Jan 2013, at 18:58, John Baldwin wrote: >> >>> I'm less certain. Note that you can't inline mutex ops until you expose >>> the mutexes themselves to userland (that is, making pthread_mutex_t not >>> be opaque). >> This is one of the things that will be required anyway if we wish to support > process-shared mutexes (they've been in POSIX since 1997, so it's probably > getting on for time we did), as the current mutex-is-a-pointer implementation > depends on the virtual address space of the creator, and so does not work if > the mutex is created in a shared memory segment. > > Yes, David Xu has a p4 branch with this done already. My point is that I > would rather effort be spent on getting that in before attempting your > suggestion for our current primitives as the inlining you do now requires > that David's changes honor the same ABI in the future. > Yes, I have such a p4 branch. The problem I encountered is binary compatibility, libthr has to have both code for old mutex which is a pointer and new mutex which is a structure, if module A passes pointer-mutex to a recompiled module B which is using structure-mutex, this is broken. And I found NVIDIA GeForce driver is using dlsym() with no version hint, it is trying to get pthread_mutex_lock and other symbols, the default version in the new libthr will return a new entry which uses structure mutex, since the driver is not open-source, so you can not recompile it, the change will break it.
Regards, David Xu _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"