From owner-freebsd-java Thu Dec 13 19:43:33 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 8BF9237B417 for ; Thu, 13 Dec 2001 19:43:30 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16EjFu-00013y-00; Thu, 13 Dec 2001 19:43:26 -0800 Date: Thu, 13 Dec 2001 19:43:26 -0800 To: Daniel Eischen Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011214034326.GA4018@gnuppy> References: <20011213063207.GA7359@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 13, 2001 at 09:05:37AM -0500, Daniel Eischen wrote: > Well, the intent of the patch is correct. The patch that you > posted (subsequent to this email) is much more than is necessary. > There should be no need to keep previous timeout times... > And in general, keeping previous anythings doesn't work due to > signal semantics. Threads are allowed to longjmp out of signal > handlers which can bypass anything the scheduler wanted to do > in regards to restoring "previous" values. I'll need to review this to get an idea of what you're talking about. > If a thread timesout, you want to prevent it from being added > to the run queue if it is suspended. As long as a thread is > not in the run queue, it will not run. If a suspended thread > is running before it is resumed, then the timeout loop (my > patch attempts to correct it) is the place to look. One of the shot in the dark reason why I still kept thread in the waiting queue and marked the timeout value as -1, is that some operation dealing with mutexes failed on an assert when it could not find the thread to remove in the waiting queue. I'm not sure where the logic for that is just yet and how to solve that problem. > I am running with my patch without any problems, and I have > passed all my regression tests. I don't have anything that > tests suspend and resume, though. Do you have a simple C > program that demonstrates the problem? Other than the JVM itself, no. I would expect that the regression tests would pass since it only triggers in cases where it deals with suspend and resume states, but trying to get a small test program to trigger what I'm running into is going to be difficult. The threads that seem to give me the problems are condition variable related. I'm not sure what to say other than that. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message