svn commit: r302194 - head/lib/libthr/thread

[Cy Schubert]

In message <20160625223338.GA22802 at 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.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.