PS_BLOCKED

[Daniel Eischen]

On Sun, 6 Apr 2003, Julian Elischer wrote:
> On Mon, 7 Apr 2003, David Xu wrote:
> 
> > 
> > ----- 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'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