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

[Tomoaki AOKI]

> 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.

It would be better fixing in ports and stay POSIX-compliant side.
For linux binaries, they would use glibc introduced by one of
linux_base-* port, so native libthr wouldn't be used. (Right?)

The problematic cases would be ported softwares primarily for Linux.
(Native binary)

Of course, the best way is to be cared inside each upstream.
(Check for glibc on configure stage, and do special care only if
needed.)
This case, we need no special care for this glibc quirks.


For FreeBSD community, there would be...

  1) Make new USES on ports framework for this regression.
  2) Patch (via files/* or REINPLACE_CMD) on each port needed.
     (No special care is needed for libthr itself.)

Unfortunately, 1) would be almost impossible without switching like you
mentioned, as methods for checking return value / error codes should
have tooo many patterns. :-(

System-wide setting wouldn't help, as there's possibilities that, for
example, console-kit (needs normal POSIX behaviour) and samba4 (needs
glibc quirks) can coexist.

IMHO, for per-binary settings, using ELF branding or alike to switch
would be better than using environment variables.

If we prefer environment variable, we'd need wrapper script especially
for pkg users, causing possible performance penalty (would be
significant for use-cases like filters). But using ELF branding, it's
stored inside the binary itself.


>
>
> -- 
> 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.

-- 
Tomoaki AOKI    junchoon at dec.sakura.ne.jp