[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: Mon, 17 Mar 2008 10:50:31 +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 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

reply via email to

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