1:1 threading.

[Julian Elischer]

On Thu, 27 Mar 2003, Jeff Roberson wrote:

> 
> The effects are less because each thread/kse is given as big of a quantum
> as each full process would.  I'm not sure if this is a bug or a feature.
> 

It's neither.. it's not what happens.
 More accuratly, it's only part of the story.

Firstly it's 'standin' code.. but it exhibis some of the desired
bahaviour. Yes, each KSE gets a quantum, but the next thread to run in
that KSE is forced to go to the end of the queue.  Effecively, this
forces the process to allow other processes with enough priority to get
CPU. This is a 'quick' solution to stopping a process with a lot of
threads from swamping the system. The plan is to put in place a more
comprehensive solution when time allows. Only one thread for each KSE
can actually be on the run queue at a time.. yes it could run for the
entire quantum, but the system will not let it put 10000 of these back
to back unless there are no other competing threads. There is room there
for a graduate student to do a project adding code to allow the KSEGRP
to allow the rest of it's quantum to be passed on to other equivalent
priority threads in the same group. This would be, as dicussed several
times, in the form of code in choosethread() that would first check for
internal threads if there was quantum left, before resorting to external
threads to run. (The trick is to get the right balance)