From owner-freebsd-java Thu Dec 13 6:10:14 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CDAAE37B41B for ; Thu, 13 Dec 2001 06:10:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBDE5bBx024639; Thu, 13 Dec 2001 09:05:37 -0500 (EST) Date: Thu, 13 Dec 2001 09:05:37 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011213063207.GA7359@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 12 Dec 2001, Bill Huey wrote: > On Wed, Dec 12, 2001 at 07:24:12AM -0500, Daniel Eischen wrote: > > > > diff -u -r1.38 uthread_kern.c > > > > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > > > > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > > > > @@ -387,6 +387,10 @@ > > > > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > > > > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > > > > switch (pthread->state) { > > > > + case PS_SUSPENDED: > > > > + PTHREAD_WAITQ_REMOVE(pthread); > > > > + pthread->suspended = SUSP_YES; > > > > + break; > > > > case PS_POLL_WAIT: > > > > case PS_SELECT_WAIT: > > > > /* Return zero file descriptors ready: */ > > > > Dan Eischen > > > > Yes, this should keep the state equal to PS_SUSPENDED. When the thread > > is resumed, its state should be set to PS_RUNNING and then it will be > > added back to the run queue. > > This didn't work. A thread would SEGV and then the entire thing blows up > shortly afterward in a wierd kind of delayed signal delivery way. 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. 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. 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? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message