In message <20160625223338.ga22...@stack.nl>, Jilles Tjoelker writes: > On Sat, Jun 25, 2016 at 08:29:56PM +0300, Konstantin Belousov wrote: > > I already asked re for approval of the reversal and got it. But I am still > > hesitating doing the revert vs. returning EDEADLK for error-checking > > mutexes. > > > My initial mistake was reading the statement about PTHREAD_MUTEX_ERRORCHECK > > returning EDEADLK as the requirement for both functions. It was induced > > by reading the following code in samba: > > https://github.com/samba-team/samba/blob/master/lib/tdb/common/mutex.c#L928 > > I did extracted this into stand-alone test and checked that glibc does > > return EDEADLK in this case. BTW, if somebody has Solaris machine availabl > e > > to test this, I would be grateful. Code is available at > > https://www.kib.kiev.ua/kib/pshared/pthread_samba.c > > > I.e., plain revert would disable the only known to me consumer of the > > robust mutexes. The patch which I mailed last time, returns EDEADLK for > > trylock on ERRORCHECKed mutexes only. And I am tending toward glibc > > compatibility there, over the literal POSIX compliance, but I want to > > see the confirmation from the Klimenko' test first. > > To be bug-compatible with glibc, you'd need to return the wrong > [EDEADLK] error for robust errorcheck mutexes only. Robust > non-errorcheck and non-robust errorcheck mutexes return the correct > [EBUSY]. I have not checked PI and PP mutexes which probably use a > different code path. > > I'm not sure whether we should copy glibc's bug, but if we do it must be > documented in the man page. I'm not happy with it because the bug may > break applications written to the standard; at least, Samba developers > should be contacted first.
I think there are advantages both in POSIX and glibc compatibility however I think it more important to be POSIX compatible. Having said that, there may be a compromise. Either setting an environment variable and/or setting a global variable (or call a function) to invoke a glibc-bug emulation mode. Thus linux-only applications could be ported with minimally invasive alterations. Either we break POSIX compatibility (and some existing applications) or we can implement the above which may satisfy both camps. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"