Re: Comments on the KSE option

    I think the real issue here is that it is fairly difficult... probably
    close to impossible in fact, to write a general purpose scheduler in
    the kernel that can handle the types of extreme cases that can occur
    when the kernel is made responsible for managing a user program's threads.

    A better approach would be to make the kernel responsible for scheduling
    cpu slots for programs, a far more manageable number, and if a program
    wants to have thousands of threads on a 4-cpu system it (i.e. libthr)
    should then have the responsibility of telling the kernel which
    threads to pop into those slots at any given moment.

    So, for example, if a machine has 4 cpus the kernel has 4 scheduling
    slots it can fill.  The kernel can apportion those slots with its current
    scheduler technology.  But if there is a program running on the system
    that has thousands of threads, then why in the world would you want to
    try to make the kernel scheduler deal with all those threads at once
    when it only has 4 cpus to assign them to anyhow?  So what you would
    have instead would be the kernel saying to the program 'ok, I have 3
    slots available for you at the moment' and make the program responsible
    for telling the kernel which threads to run in those 3 slots.  And
    then a little while later the kernel might say 'I have 4 slots now',
    or 'now I only have 2 slots available', etc etc.

    This would then be a far more solvable problem for the kernel scheduler.

    If you as the user then want the kernel to give the program with
    thousands of threads more of the available cpu, it simply becomes a
    matter of running the program at a lower NICE value.

						-Matt