Messages in this thread | | | Subject | Re: context switch vs. signal delivery [was: Re: Accelerating user mode | Date | Tue, 06 Aug 2002 13:42:18 -0400 | From | Jeff Dike <> |
| |
us15@os.inf.tu-dresden.de 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 sigio_handler.
Any other possibilities that you see?
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |