PS_BLOCKED

[David Xu]

----- Original Message ----- 
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "David Xu" <davidxu at freebsd.org>
Cc: <freebsd-threads at 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 at pcnet1.pcnet.com>
> > To: "DavidXu" <davidxu at freebsd.org>
> > Cc: <freebsd-threads at 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.

> > > 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.

> > >  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.

> > > -- 
> > > Dan Eischen
> > > 
> > > 
> > > Let's Go Orange!
> > 
> > Would there be a new patch against code in the src tree 
> > I can download ?
> 
> Done.  I'll try to do some more debugging and update it again
> later today.
> 
>   http://people.freebsd.org/~deischen/libpthread.diffs
> 

Got it!

> -- 
> Dan Eischen