Fast sigblock (AKA rtld speedup)

[David Xu]

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