Call for Developers! Userland threading

[Peter da Silva]

   An upcall is probably the best way, though as with our IPI messaging
   the kernel would not necessary *have* to always upcall, it could just
   queue the returned message and let the userland pick it up in its own
   good time.

So it sounds like theres going to have to be some user backing code to 
register a sort of handler.
userapi would do that transparently to the application, when appropriate 
messages. As Matt said, it may be that it's best to always preempt,
but I think that could end up with a lot of unnecessary kernel-user
transitions... if the application is only notified when it asks to
be notified an I/O driven applications using an event-loop style API
(either raw dragonfly messages or a non-UNIX userapi) would only get
a maximum of one kernel transition per Wait(). Think of it as the
flip side to the bundled system calls.

Preemption is needed to allow signals to catch 
at all if you were caught in a tight loop (unless kernel takes over like 
KILL).
Well, if the signal is set to SIG_DFL then the application will
be killed when the signal arrives. If it's set to SIG_IGN then it
doesn't get notified. The only place preemption matters is when
there's a handler registered *and* there's a CPU-intensive loop
with no system calls ever being made. That's actually a pretty
rare situation.