Re: Call for Developers! Userland threading

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

    Well, we have IPI messaging to consider too, or whatever the IPI
    abstraction becomes in userland.  i.e. for things like scheduling 
    to another cpu, and so forth.

    This pretty much requires that the userland system be capable of
    doing the preemption approach.  And critical sections would
    also have to be handled (basically a direct port of LWKT from the kernel
    into userland, including all the bells and whistles).

    The 'signal' message might be received during such a preemption, but
    then what the userland threading system does with it will depend on
    how the user wants it handled.  e.g. queue for later processing, take
    immediately, forward to another (virtual) cpu, etc.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>