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

From: Jeff Dike (
Date: Tue Aug 06 2002 - 12:42:18 EST said:
> I'm glad we agree on that one :)

Yup, sorry. That test is wrong, and is slated to be fixed at some point.

> When the task is registered as socket owner and is just about to enter
> the kernel due to a syscall, it will stop with a SIGTRAP and the
> tracing kernel process will run sometime and see a SIGCHLD. But after
> the task stopped and before the kernel process can change SIGIO
> ownership back, a new interrupt could come in and the SIGIO would
> remain pending in the task's process until the task was scheduled to
> run next time.
> How do you solve this?

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.

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

Any other possibilities that you see?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:32 EST