Date: Thu, 13 Dec 2001 09:05:37 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Bill Huey <billh@gnuppy.monkey.org>, freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <Pine.SUN.3.91.1011213084638.21236A-100000@pcnet1.pcnet.com> In-Reply-To: <20011213063207.GA7359@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1011213084638.21236A-100000>