Date: Tue, 27 Apr 2004 10:47:21 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@FreeBSD.org> Cc: David Xu <davidxu@FreeBSD.org> Subject: Re: kse_release and kse_wakeup problem (fwd) Message-ID: <Pine.GSO.4.10.10404271041260.22187-100000@pcnet5.pcnet.com> In-Reply-To: <200404270947.08523.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Apr 2004, John Baldwin wrote: > On Monday 26 April 2004 01:38 pm, Daniel Eischen wrote: > > On Mon, 26 Apr 2004, Daniel Eischen wrote: > > > > > > I'm experimenting with adding an wakeup_thread() to kern_thread.c > > > (to complement wakeup() and wakeup_one()). If we shouldn't be > > > using sleepq's directly, the thread code either needs to > > > > > > a) queue msleep()'ing upcalls/threads itself having them > > > all block on on their own unique wchan's; or > > > > > > b) use a wakeup_thread() that wakes up a specific thread. > > > > Sorry, patch for b) is at: > > > > http://people.freebsd.org/~deischen/sys.diffs > > Erm, does sleepq_signal_thread() do anything different than sleepq_remove() > (removes a thread from a specified wait channel if and only if the thread is > sleeping on that wait channel)? I guess not. I thought we would have to search the list of threads to ensure it was queued. I've updated the patch slightly -- added thread_upcall_check() and changed where the new thread flags are stored: http://people.freebsd.org/~deischen/sys.diffs If I remove sleepq_signal_thread() and use sleepq_remove() instead, does the patch look OK to you? Thanks, -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404271041260.22187-100000>