Date: Sun, 31 Oct 2004 10:40:46 -0500 From: Brian Fundakowski Feldman <green@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_mutex.c Message-ID: <20041031154046.GU93831@green.homeunix.org> In-Reply-To: <4184BD2D.9030209@freebsd.org> References: <200410310503.i9V53ofj011896@repoman.freebsd.org> <20041031050620.GQ93831@green.homeunix.org> <4184BD2D.9030209@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041031154046.GU93831>