PS_BLOCKED

[Julian Elischer]

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()".

I think kse_release should be left alone.
It should never return.

> 
> > > >  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
> 
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>