[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 #6 from Rob Clark <robclark at freedesktop.org> ---
(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.

> 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 ;-)

pthreads-stub should only be used where you don't actually have *any* threads..
so in that regard, stubbing pthread_mutexattr_settype() is completely legit.

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.

-- 
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/20161006/a20f8fbc/attachment-0001.html>