Date: Sun, 6 Apr 2003 23:36:44 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <Pine.GSO.4.10.10304062334400.15892-100000@pcnet1.pcnet.com> In-Reply-To: <003501c2fca3$3e20c900$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
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've still got one bug I am trying to hunt down with > > > > signals -- the sigwait test fails. Process (kill) signals > > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > > if it is a kernel bug or not, but I suspect it's > > > > something I'm doing. > > > > > > > > > > I don't know if Jeff's signal change in kernel affects your code, > > > but signals lost problem is still not fixed, a thread exports its > > > context and exits would lost signals dispatched to it, even the > > > signals is not for the thread, but for process. > > > > 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. Ok. We need to fix that somehow. > > > > 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. That would be convenient. > > > > And if kse_A->k_mbx.km_curthread == NULL > > > > and it is in a kse_release(tsp), can another kse > > > > interrupt it (before the timeout) with kse_wakeup()? > > > > > > > Yes, you can use kse_wakeup to interrupt it, pass the > > > kse mailbox address to the syscall. > > > > Cool, that's what I thought. > > > > I forgot to mention it, but I think I found a kernel bug also. > > Sometimes when the kernel exports a context to the UTS the > > %gs register isn't set; it doesn't seem to be saved in some > > instances. I think it might only be when a kernel thread > > is swapped out (without blocking). Does %gs always get saved, > > even if the thread is interrupted by an interrupt? > > > > Yes, I will fix it and give you a patch. Thanks. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304062334400.15892-100000>