Date: Tue, 8 Apr 2003 09:05:03 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com>, "Julian Elischer" <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) Message-ID: <006601c2fd6a$e2b79d00$f001a8c0@davidw2k> References: <Pine.GSO.4.10.10304071354450.3533-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel, These are optimizations, right? Could we stablize the libpthread before optimizing it? Is per-kse problem resolved? I don't stick to this,=20 and if you think it should be resolved now, I would like to work on it. David Xu ----- Original Message -----=20 From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> To: "Julian Elischer" <julian@elischer.org> Cc: "David Xu" <davidxu@freebsd.org>; <freebsd-threads@freebsd.org> Sent: Tuesday, April 08, 2003 2:07 AM Subject: Scope system threads (was Re: PS_BLOCKED) > Rethinking scope system threads a bit... >=20 > Here's what I'd like for scope system threads: >=20 > 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(). >=20 > --=20 > Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006601c2fd6a$e2b79d00$f001a8c0>