:How's about we define what a KSE is, a SA is, and come up with some :other term for a userland 'thread'? : :It seems that Julian is using the same term for a userland thread and a :context that can go into the userland as a KSE, but I'm not sure. : :Assuming for a moment that this is the case, then is a SA a 'kernel

The terminology I have been using, which I thought was the same as Julian's but may not be, is:

Thread

Two entities. A kernel structure 'Thread' and also a similarly named but independant user structure within the UTS.

KSE

A kernel scheduleable entity. I was using this to mean the contextual information (such as a kernel stack) required for the kernel to be able to run a thread. Not required for runnability, only required to actually run the thread and also held over of the thread blocks while in the kernel.

Process

Our good old process.

I think I actually misspoke earlier. Runnability in the kernel scheduler is governed by 'Thread', not 'KSE' with my idea. Only currently running contexts require a KSE. i.e. you might have 10 runnable Threads linked into the kernel's scheduler but if you have a two-cpu system, only 2 of those 10 will actually be running at any given moment and require KSE's.

With my system we change the kernel scheduling entity from a 'Process' to a 'Thread' and a Thread can then optionally (dynamically) be assigned a KSE as required to actually run.

The KSE is a kernel abstraction and essentially *invisible* to user mode. The Thread is a kernel abstraction that is visible to user mode.