Scope system threads (was Re: PS_BLOCKED)

[David Xu]

Daniel,

These are optimizations, right?
Could we stablize the libpthread before optimizing it?
Is per-kse problem resolved? I don't stick to this, 
and if you think it should be resolved now, I would like to
work on it.

David Xu

----- Original Message ----- 
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "Julian Elischer" <julian at elischer.org>
Cc: "David Xu" <davidxu at freebsd.org>; <freebsd-threads at freebsd.org>
Sent: Tuesday, April 08, 2003 2:07 AM
Subject: Scope system threads (was Re: PS_BLOCKED)


> Rethinking scope system threads a bit...
> 
> Here's what I'd like for scope system threads:
> 
>   o No separate upcall stack; only ever gets one upcall
>     after kse_create() is called.
>   o Still has a thread mailbox in which the lone thread's
>     signal mask is placed.
>   o The UTS can deliver signals to scope system threads
>     with kse_thr_interrupt(&scope_system_thread->tmbx, sig)
>     or equivalent.  Since there is no upcall stack, you
>     can't make an upcall with kse_mbox->km_sigscaught; you
>     need to send it a signal just like it was a regular
>     non-KSE thread.
>   o Can wait for KSE events from other KSE/KSEGs with
>     kse_release(&ts).  After receiving a wakeup or timing
>     out, kse_release just returns normally -- no upcall.
>     Typically, we need to wait for low-level locks or
>     pthread_cond_[timed]wait().
> 
> -- 
> Dan Eischen