[Xcb] [Bug 98048] libpthread-stubs must NOT provide symbols which depend on actual implementation

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 7 18:09:18 UTC 2016


https://bugs.freedesktop.org/show_bug.cgi?id=98048

--- Comment #13 from Rob Clark <robclark at freedesktop.org> ---
(In reply to Emil Velikov from comment #11)
> (In reply to Rob Clark from comment #6)
> > so in that regard, stubbing pthread_mutexattr_settype() is
> > completely legit.
> > 
> Not really :-\ AFAICT setting/changing the mutexattr implies that one
> requires actual locking.

Well, to be super-anal, pthreads-stub should perhaps flag an error or assert or
something for non-recursive mutex if recursively acquired.  But I guess no one
has cared about that so far.  It doesn't help that the default mutex type can
be (but doesn't have to be) recursive.

But I don't see how setting mutexattr implies that you require locking in a
single-threaded environment any more than pthread_mutex_lock() does.  So I
still think stubbing the mutexattr fxns is not wrong..  but I guess there is an
unfortunate interaction with how pthread syms that aren't in libc get resolved?
 Maybe reverting the stubs is more convenient than fixing glibc if we can't
figure out how to get the symbols from libpthread before pthread-stubs.

That said, all I have of pthreads-stubs in my filesystem is the .pc file, which
I guess explains why I am not seeing this issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xcb/attachments/20161007/c5c37864/attachment.html>


More information about the Xcb mailing list