<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#c11">Comment # 11</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:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c6">comment #6</a>) > (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. > 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.</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>