cvs commit: src/lib/libpthread/thread thr_mutex.c

[Brian Fundakowski Feldman]

On Sun, Oct 31, 2004 at 03:23:41AM -0700, Scott Long wrote:
> Brian Fundakowski Feldman wrote:
> >On Sun, Oct 31, 2004 at 05:03:50AM +0000, Brian Feldman wrote:
> >
> >>green       2004-10-31 05:03:50 UTC
> >>
> >> FreeBSD src repository
> >>
> >> Modified files:
> >>   lib/libpthread/thread thr_mutex.c 
> >> Log:
> >> Make pthread_mutex_trylock(3) return EBUSY on failure, as all software
> >> packages expect and seems to be most correct according to the slightly-
> >> ambiguous standards.
> >> 
> >> MFC after:              1 month
> >> Corroborated by:        POSIX <http://tinyurl.com/4uvub>
> >> Reviewed by:            silence on threads@
> >
> >
> >Software such as mozilla projects (using NSPR) and Java have been
> >broken in various ways by this.  We need to try to be more compatible
> >with the most popular interpretation of the standards (instead of just
> >inventing our own) -- usually we're pretty good about this.
> >
> 
> Please define 'broken'?  There are many test suites available for 
> pthreads.  How does this affect those test suites, and have you
> _directly_ talked with those who run the tests suites?

It causes them to _FAIL_.  Try to build a mozilla port without the
FreeBSD-specific pthread_mutex_trylock(3) workaround, with debugging
turned on, and without the removal of EDEADLK from the function.
We break the assertions that software developers use when writing to
the pthreads API, and then when we "port" applications written to
standard POSIX threads implementations in Solaris, Linux, etc., we
have to modify them to catch this.

Have you tried any of the test suites?  The POSIX-provided-for-free
one does not have coverage of error return values from what I can see,
and the Linux pthreads ones also don't test this because as far as they
are concerned, it's a code invariant, and the implementation which they
control is not going to start returning EDEADLK one day.  The FreeBSD
one has similar issues (lack of coverage ones) but additionally is
exceedingly moldy and if it were actually a "regression" test we'd fail
it because half of them do not produce expected results.  What other
ones do you want me to try?

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\