[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread model

From: Neal H. Walfield
Subject: Re: Thread model
Date: Wed, 12 Mar 2008 20:46:11 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 12 Mar 2008 15:32:26 -0400,
Thomas Bushnell BSG wrote:
> On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote:
> > What you are suggesting is essentially using a user-level thread
> > package.  (Compacting a thread's state in the form of a closure is a
> > nice optimization, but the model essentially remains the same.)  The
> > main advantage to user-level thread package is that the thread memory
> > is pagable and is thus less likely to exhaust the sparser kernel
> > resources.  In the end, however, it suffers from the same problems as
> > the current approach.
> Cthreads does this.

Does what?  The cthread implementation found in hurd/libthreads uses
one kernel thread per user thread.

> Still, the issue is the thread stacks; even if you are using multiplexed
> user threads, each user thread still needs a user stack.

Yes, that is what I tried to say, sorry if it wasn't clear.  My
suggestion was to use one thread per CPU and to make methods
restartable so that should an RPC ever need to wait for a resource, we
just add the message buffer to the object's wait queue (perhaps using
push-back, e.g., reply to client: try message again using this
capability, which identifies the wait queue).  When the object becomes
unblocked, the message is requeued.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]