Date: Sun, 31 Oct 2004 17:12:19 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_mutex.c Message-ID: <Pine.GSO.4.43.0410311703030.23450-100000@sea.ntplx.net> In-Reply-To: <20041031154046.GU93831@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0410311703030.23450-100000>