KER,THREAD arf 1 - Thread definition (GREAT!)

[Dennis Marer]

Howdy!

	I like Fare's definition of a thread.  It seems like a complete
definition and the ideal path to pursue in our system.  I also like how tasks
and threads are one and the same, except a thread shares the memory space
of its (task) parent.  Looks good!

> The task specific concept is available only if hardware support special
> task managing as with the i386 cpu. But this has to do with implementation,
> and not with moose specifications.

I think it would be possible to implement tasks on devices which do not
have these functions built in as well.  The 386 swaps tasks automatically
using a jmp or call instruction which just saves the state of the machine
and loads another task's state as well.  This would be easy to do with most
machines.  For example, the 68k: Push all registers (one instruction) then
save the stack pointer in the process table.  To restore a task, load its
stack register, pop all registers, and return.

The point I'm trying to make is that the concept of a task is easy to
implement even on a system which doesn't explicitly have it in hardware.
>From the programmer's point of view, nothing is different.  It may be a little
slower, but is still identical.

One question I have is this: what kind of information is associated with a
task?  Memory space, of course, but what else?  Accounting (time, etc) info?
This will need to be specified eventually, but is not vital yet.

**

I've decided that I tend to look at the implementation aspect of things where
a lot of you tend to look at the theory aspect.  Just an observation...
I think its good to get both points of view!

Do you realize I've received over 1.2 megabytes of mail from you in the past
two months?  I think that's great!

			Dennis