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

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

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Tue, 06 Aug 2002 13:42:18 -0400
Jeff Dike <jdike@karaya.com> wrote:

> A couple of ways.  The system call path can call sigio_handler to clear
> out any pending IO.  The SIGIO that was trapped in the process will cause
> another call to sigio_handler which won't turn up any IO, but I don't 
> consider that to be a problem.

It is not a problem at all, just a small performance penalty.

> The kernel process can examine the signal pending mask of the process after
> it has transferred SIGIO to itself.  This can be done either through 
> /proc/<pid>/status or a ptrace extension, since we're happily postulating 
> new things for it to do anyway.  If there is a SIGIO pending, it calls
> sigio_handler.

I don't like the idea of having to fiddle with the proc filesystem. Some
people might not even mount it. A ptrace extension to look at and modify
the pending signal mask of a traced process would be very handy.

> Any other possibilities that you see?

Right now I'm doing something hackish. If the process enters with a syscall
(int 0x30 in my case) after the kernel expects it to enter due to an interrupt,
I just restart the task until it enters with the pending interrupt signal (SIGIO).
The task will do that before it can step on the int instruction again, and after
it returns to usermode it will step on the int again. This works well with faults.
The problem are traps, because the EIP points behind the instruction. In that
case the EIP needs to be adjusted. Ugly, I know.

-Udo.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]