From owner-cvs-all@FreeBSD.ORG Sun Oct 31 22:12:21 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A27416A4CE; Sun, 31 Oct 2004 22:12:21 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8EF243D2F; Sun, 31 Oct 2004 22:12:20 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i9VMCJFh017733; Sun, 31 Oct 2004 17:12:19 -0500 (EST) Date: Sun, 31 Oct 2004 17:12:19 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Brian Fundakowski Feldman In-Reply-To: <20041031154046.GU93831@green.homeunix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: Scott Long cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_mutex.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2004 22:12:21 -0000 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 > > >> 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