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

[Daniel Eischen]

On Sun, 31 Oct 2004, Brian Fundakowski Feldman wrote:

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

If you're talking about the FreeBSD mutex test (libpthread/test/mutex_d.c),
that should work.

-- 
Dan Eischen