Subject: Re: The Right Way to implement threads?
To: Jason R Thorpe <email@example.com>
From: Matthew Orgass <firstname.lastname@example.org>
Date: 06/10/2000 16:13:13
On Fri, 9 Jun 2000, Jason R Thorpe wrote:
> On Sat, Jun 10, 2000 at 01:58:40AM -0400, Matthew Orgass wrote:
> > [Actually, I think Jason Thorpe recently said that there is not much
> > stopping kernel threads from being preemptable now. But this is not
> > required for my method.]
> Um, I never said anything of the sort.
Sorry about that. Did you just say the locking mechanisms needed were
almost in place, or did I imagine the whole thing?
> > > Besides that, I'm not sure it makes sense. The resources being
> > > consumed by the kernel thread are its kernel stack, which isn't
> > > something that can be thrown away even if it is preempted.
> > Why not?
> For a very obvious reason -- the kernel stack (and U-area) for that
> thread holds the state of that thread at the time of preemption.
Ah, right. But if it was actually canceled, then there would be no
state to keep.
I did realize that in order for my method to work kernel threads in long
term wait must be able to be canceled, wait in kernel on the resource
needed without a kernel thread, and be restarted without returning to
userland. This would be possible if in addition to the kernel stack each
thread had a way to specify a certain amount of state that would be
preserved if the thread was canceled.
So, I guess this is a case of a lot of work for relatively little gain.
If I decide to try implementing it, I won't bother the list with it unless
I have working code.