From owner-freebsd-threads@FreeBSD.ORG Mon May 5 21:45:58 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E85637B404 for ; Mon, 5 May 2003 21:45:56 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1138C43F3F for ; Mon, 5 May 2003 21:45:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CuKr-0007Tj-00; Mon, 05 May 2003 21:45:50 -0700 Message-ID: <3EB73DA9.B0F0C647@mindspring.com> Date: Mon, 05 May 2003 21:44:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen , David Xu , threads@freebsd.org References: <3EB7256E.844A5958@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4506da5bbbb226c84d260680814129660387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 04:45:58 -0000 > Daniel Eischen wrote: > > > Personally, I don't think this is justifiable, and that the > > > problem is actually a coding error in the threaded program, > > > with failure to comply with the POSIX and Single UNIX > > > Specification when writing your threaded program. The pthreads > > > documentation seems to back me up (Chapter 12 of "Go Solo 2", > > > as well as Corrigenda). > > > > It *is* an rtld-elf problem. I've protected dlfoo() all with the > > same mutex and it still hangs. rtld-elf uses spinlocks in > > areas that aren't called by dlfoo(). Rather than pointing at the standards over and over again, it occurs to me that I should ask you a question, instead, to emphasize our disconnect; so here it is: If my theory of operation for the bug was incorrect, can you tell me *why* my suggested scheduler workaround fixed it, instead of having no effect or only a partial effect? Thanks, -- Terry