Call for Developers! Userland threading

Peter da Silva peter-dragonfly at taronga.com
Tue Jul 22 16:54:19 PDT 2003


Craig Dooley wrote:
The upcall system of KSE seems like the best way to preempt a process for 
signals.  Even though there should only be one message port from what I 
understand, what about 2, and having one do an upcall for things which need 
immediate attention?  If im misunderstanding and every time a message is 
receive it jumps to a handler just ignore me.
The question isn't whether there's one port or two, but what you
do about the signal once it reaches user space.
	1. Preempt the current thread and start it running the
	   signal handler.
	2. Preemptively switch to the thread that registered the
	   handler and start running the signal handler.
	3. Cooperatively run the signal handler in the next
	   available thread.
	4. Cooperatively run the signal handler in the thread that
	   registered it.
	5. Preempt the current thread and run the signal handler
	   in a special signals thread.
	6. Cooperatively run the signal handler in the signals
	   thread.
There are advantages and disadvantages to all of these.

The cleanest way to do it would be for the signal() call request
that signals be delivered to the process's reply port as messages
for the thread that registered the signal handler, and Wait()
would deal with these messages by running them in that thread
when it calls Wait() after completing a signal handler (remember,
userland threads are cooperative, so when Wait() gets that message
that thread *is* in Wait() already, so it only needs to check if
it's handling a signal.
The downside is that if you're looping and not calling Wait() the
signal handler can be indefinitely deferred. There are a number of
ways to handle this, but they all involve a moderate amount of
bookwork so it's probably best to set that aside until later.





More information about the Kernel mailing list