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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Emil Velikov <emil.l.velikov at gmail.com> ---
(In reply to Rob Clark from comment #6)
> (In reply to Emil Velikov from comment #5)
> > I believe Ian's explanation perfectly reasonable, but let me try from
> > another angle:
> 
> My confusion wasn't about the problem of mixing/matching pthreads-stub and
> real pthreads fxns.. that is completely obvious.
> 
> The confusion was about how it worked at all before when
> pthread_mutexattr_init()/etc wasn't provided, and if the libc doesn't
> provide a recursive mutex feature.
> 
My take is that an actual implementation (likely libpthread.so) is/was used
throughout. At least it should have been ;-)

> > libpthreads-stub must _not_ provide stub implementation for APIs that
> > absolutely requires locking/other. Would that be pthread_mutexattr_settype
> > or any other.
> 
> or pthread_mutex_lock()/unlock() for that matter ;-)
> 
Almost. If you don't require actual locking (!recursive + single thread) they
can be empty stubs.

> pthreads-stub should only be used where you don't actually have *any*
> threads..
Agree.

> so in that regard, stubbing pthread_mutexattr_settype() is
> completely legit.
> 
Not really :-\ AFAICT setting/changing the mutexattr implies that one requires
actual locking.

> The problem *sounds* like we somehow have a libc that provides *part* of the
> pthreads API, but not all, so you end up mixing stub and real
> implementation?  But if that is the case, doesn't that mean that mutexes end
> up not being recursive, which sounds like a bad thing..  at least this is
> what I am reading between the lines here.  I'm not entirely sure which libc
> we are talking about here.

Both libc and libpthreads-stub provide weak symbols for some of the 'safe'
pthread API. In practise the libpthread.so symbols should override them and I'm
not 100% sure how we end up using the libpthreads-stubs
pthread_mutexattr_settype(), which in itself causes the problem.

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