Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2001 17:22:18 -0800
From:      Bill Huey <billh@gnuppy.monkey.org>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        Bill Huey <billh@gnuppy.monkey.org>, Nate Williams <nate@yogotech.com>, absinthe@pobox.com, shanon loveridge <shanon_loveridge@yahoo.co.uk>, freebsd-java@FreeBSD.ORG
Subject:   Re: Pthreads bug fix [was Re: jdk1.3.1p5]
Message-ID:  <20011212012218.GA3199@gnuppy>
In-Reply-To: <Pine.SUN.3.91.1011211180304.28589A-100000@pcnet1.pcnet.com>
References:  <20011211223318.GB2002@gnuppy> <Pine.SUN.3.91.1011211180304.28589A-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 11, 2001 at 06:12:37PM -0500, Daniel Eischen wrote:
> > 3) The waiting queue recalculation stuff seems to be logically ok, but
> > 	was also sloppily glued together. I only marginally care for the
> > 	same reason as above. ;-)
> 
> Not sure why this is needed.  In general, wait times are in absolute
> times and blocking conditions internal to the threads library should
> be able to handle errant wakeups (so they don't return to the caller).
> This is essential for signal handling to work properly.  If a thread
> waiting on a mutex or condition variable has to handle a signal, it
> needs to dequeue itself from the mutex/cv queue, run the signal handler,
> and then it returns to the mutex or cv routine (which detects the
> errant wakeup, requeues the thread, and calls the scheduler to block
> and schedule another thread again).

Maybe a different kind of suspend operation is needed or the semantics
of how I interpreted it should be different in that when the GC thread is
run, that should block out and prevent any thread from running, changing
state to waking until it's done with the collection. Maybe I should allow
it to timeout and then only change state to PS_COND_WAIT, etc... at the
point where it gets resumed.

What do you think ?

> > In summary, I'm basically lazy and would like you to fix all the
> > problems with it. ;-)
> 
> That didn't look like a patch to -current libc_r; was it?

I'm not running -current, so I don't know.

bill


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?20011212012218.GA3199>