Re: context switch vs. signal delivery [was: Re: Accelerating user mode

["Udo A. Steinberg" <us15@os.inf.tu-dresden.de>]

On Mon, 05 Aug 2002 19:42:31 -0500
Jeff Dike <jdike@karaya.com> wrote:

> Similarly, with other signals, like the timer, SIGIO, or page faults, it
> would just annull the signal and call into the IRQ system.  Although page 
> faults will be difficult because of the inability to read err or cr3, as 
> you've pointed out.

Jeff,

If my understanding of UML is right, you implement interrupts with socket
pairs where the interrupt handler writes a byte into one end and the other
end receives an async notification (SIGIO). In order to stop the right task
with a SIGIO, you change the socket owner on each context switch using fcntl.

If you have one process per task and a kernel process, the kernel process
cannot change socket ownership over to the next task's process, because it's
not allowed to. Only the process itself could set the ownership to his pid,
but then each task switch would have to be done with a trampoline too.

The issue boils down to how the kernel process can stop a task process in
order to force the task into kernel. You can of course kill (taskpid, SIG)
but that has a race if the task tries to enter kernel at the same time.
SIG will be pending in the task until it is scheduled next.

-Udo.