At Sun, 16 Mar 2008 08:01:22 +0100, <[EMAIL PROTECTED]> wrote: > On Tue, Mar 11, 2008 at 12:10:17PM +0100, Neal H. Walfield wrote: > > > > using some kind of continuation mechanism: Have a limited number of > > > threads (ideally one per CPU) handle incoming requests. Whenever > > > some operation would require blocking for some event (in the case of > > > diskfs, waiting for the underlying store to finish reading/writing), > > > the state is instead saved to some list of outstanding operations, > > > and the thread goes on handling other requests. Only when the event > > > completes, we read the state back and continue handling the original > > > request. > > > > 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. > > I don't agree it's equivalent -- not in any meaningful sense.
You need kernel memory for the memory maps, at least one for each user thread.
