Re: Thread model

[olafBuddenhagen]

Hi,

On Mon, Mar 17, 2008 at 10:50:31AM +0100, Neal H. Walfield wrote:
> 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.

No I don't. That's precisely where it is *not* equivalent.

In the model I described, the state structures for the blocked requests
(I prefer not to talk about user threads here -- it's possible to use
that abstraction, but it only seems to be confusing) are ordinary user
space data structures, living on the heap. The kernel has nothing to do
with them.

It is true that the server process pays for the storage used by these
data structures, which is not ideal of course. But it is *much* better
than the current situation, where the thread structures are much larger,
and provided by the kernel.

-antrik-