Hi! > > Since there was recently a discussion about this on glibc ML and some > > clarfication requests for Austin Group were created, I would wait a > > little more until the POSIX is clear on how this locks should behave and > > then we can fix the tests (and possibly skip them on glibc). > > > > See: > > > > http://austingroupbugs.net/view.php?id=722 > > http://austingroupbugs.net/view.php?id=720 > > > Hi Cyril, > > How about the discuss status? It's a POSIX SPEC bug? Do we need to fix our > test suite?
I haven't been following the discussion for a while, I've read the resolutions now. So they removed the contradicting line from pthread_rwlock_wrlock() and clarified the deadlock conditions. If I understand the changes right, the write locks can now be implemented to take precedence before the read locks, the testcase is correct (actually three testcases pthread_rwlock_unlock_3-1, pthread_rwlock_rdlock_2-1 and pthread_rwlock_rdlock_2-2) and the ball is on glibc side. I will write a mail to the glibc ML to discuss it. -- Cyril Hrubis [email protected] ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
