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. Neal
