Just because there aren't many apps that you know of doesn't mean
there aren't any at all, nor that there is no potential for growth in
this area. There are a lot of apps that use state threads, which is
essentially a non-preemptive analog to scheduler activations. This
is very useful for applications that have to handle a lot of small
tasks that have to process work pipelines where each step in the
pipeline involves a wait for some event to occur - either another
thread to finish doing something, or for I/O to complete.
It might seem like there's no benefit to the I/O completion bit, but
the fact is that if you have a ton of I/O going on, it's likely that
many I/Os will be complete at any given time. There's only a single
context switch back from the kernel required to signal all of these
completions if you are using something like select or poll, or even a
kernel event queue socket. So although you do not reduce your thread-
I/O-related context switches to zero in this case, you do cut them
roughly in half. And it's actually *easier* to code for than the
inside-out event loops you have to write for straight event-driven I/O.
It may be that there are no applications that you know of that make
use of this capability (and, to be honest, I am not sure that the
NetBSD SA implementation itself even supports it). But there is
major performance winnage to be had in multiplexing I/O using userland
threads, and it certainly *could* be taken advantage of by a state
threads implementation.
Being a big fan of the whole OLPC/EEPC small computing revival, things
that make multithreading really efficient on slow uniprocessor
machines are important to me, but I realize that this is not the case
for everybody, and I'm not trying to make a recommendation as to what
path NetBSD should proceed upon. I'm just sayin', there is serious
value in userland threads. They're certainly doing their part to pay
my bills. And no, not with Erlang - with plain old C.
