<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation" href="https://bugs.freedesktop.org/show_bug.cgi?id=98048#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation" href="https://bugs.freedesktop.org/show_bug.cgi?id=98048">bug 98048</a> from <a class="email" href="mailto:robclark@freedesktop.org" title="Rob Clark <robclark@freedesktop.org>"> Rob Clark</a> <pre>(In reply to Emil Velikov from <a href="show_bug.cgi?id=98048#c5">comment #5</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>