Date: Sun, 6 Apr 2003 23:45:50 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <Pine.GSO.4.10.10304062337070.15892-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0304062011280.55025-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Apr 2003, Julian Elischer wrote: > On Mon, 7 Apr 2003, David Xu wrote: > > > > > ----- Original Message ----- > > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > > To: "David Xu" <davidxu@freebsd.org> > > Cc: <freebsd-threads@freebsd.org> > > Sent: Sunday, April 06, 2003 8:39 PM > > Subject: Re: PS_BLOCKED > > > > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > > > ----- Original Message ----- > > > > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > > > > To: "DavidXu" <davidxu@freebsd.org> > > > > Cc: <freebsd-threads@freebsd.org> > > > > Sent: Sunday, April 06, 2003 2:40 PM > > > > Subject: Re: PS_BLOCKED > > > > ... > > > > > > I'll do some more debugging today and see if it is in the > > > UTS or the kernel. > > > > > > > Note that Jeff's change to signal code in kernel also broke > > our kse_release code, because the upcall thread is waiting for > > signal in kse_release too, but now it is possible the upcall > > thread won't receive any signal, signal is delivered to a > > non-upcall thread and lost. > > > > > > > One question. What happens when kse_release(tsp) is > > > > > called when k_mbx.km_curthread == NULL? Does it > > > > > just return after the timeout, or is there a new > > > > > upcall? > > > > > > > > A new upcall will be scheduled, does not return. > > > > > > Is there a way that we could get it to just return? I would > > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > > KSE/KSEG) work without a separate scheduler stack. We > > > should be able to do everything from the thread's stack. > > > I'd be willing to add a flag or something to the KSE > > > mailbox to get this behaviour. > > > > > > > It can be done by add a flags to kse_mailbox.km_flags to > > tell kernel to not schedule an upcall. > > If you have this behaviour, please make it an option. Possibly > One way to do this would be to call kse_create, with the > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > However why do you want to use kse_release for this. > If you have only one thread in the KSEGRP then I'd call this > "usleep()". It's so that the common code (called by both scope system threads and scope process threads) can be the same. I don't want to have to add checks all over the place to see if the KSE is bound to a thread or not. Also, nanosleep doesn't work well because you can't wake it up with a KSE mailbox (kse_wakeup), plus there's a race condition if you try and wake it up before it actually gets to the kernel to sleep. The kse_wakeup() call is latched, so if it gets to the kernel first, the next kse_release() will notice it. > I think kse_release should be left alone. > It should never return. Actually, I think it should obey all the rules that system calls do. If the mailbox pointer is NULL, it returns normally (after timing out or getting woken up); otherwise an upcall is scheduled. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304062337070.15892-100000>