Re: Call for Developers! Userland threading

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

> >    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.