![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:22 [W:0.177 / U:0.180 seconds] ©2003-2008 Jasper Spaans | |||||||||||||