First, it would be really nice for someone to implement
{get,set,make,swap}context(), but that is a userland thing.


After poking around at various threads packages, I started to wonder
why I'm more or less playing games with the kernel, rather than having
the kernel help me.

By playing games, I mean capturing and fiddling with signals, using a
virtual time alarm to trigger thread context switches, handling all
the I/O internally, etc.  I could just as easily have the kernel
manage at least some of this for me, such as delivering signals to
threads, handling thread context switches, and perhaps even some level
of I/O and timer work.

In short, I think the kernel should manage at least some of the
process's thread queues.

For instance, if the kernel managed the runable thread queue, it
could, on every scheduler tick, decide if it should switch to another
thread or not.  A syscall could be provided to tell it not to (for
thread-atomic operations) and when it was safe again.

Another syscall could create (or at least hand off to the kernel) the
thread-state information.

Another syscall would alter a thread, moving it from one queue to
another, perhaps terminating the thread completely.

And so on.

The first problem I see is blocking I/O.  Right now, we cannot handle
the case where multiple threads are reading or writing to the same
device, or more simply, are asleep via tsleep().  Also, many things in
the kernel assume a process, not a thread, is waiting on an event,
holds a lock, etc.

How hard would it be to extend the tsleep() functions to handle a
(process,thread) tuple, rather than just a process?  Or is this even
the right way to go?

What other problems would appear when trying to make the kernel
thread-aware?

--Michael