Re: Thread model

[Neal H. Walfield]

At Sun, 16 Mar 2008 08:01:22 +0100,
<olafBuddenhagen@gmx.net> 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.