Messages in this thread | | | Subject | Re: context switch vs. signal delivery [was: Re: Accelerating user mode | Date | Thu, 08 Aug 2002 12:19:59 -0500 | From | Jeff Dike <> |
| |
us15@os.inf.tu-dresden.de said: > The task is uncooperative and doesn't dequeue signals itself. When it > gets a signal it stops. The kernel then sees the signal and accepts it > using sigwaitinfo, at which point it is no longer pending in the task > either. The siginfo structure then provides the necessary info, i.e. > which fd caused the i/o.
I think this is more or less what I had in mind. The thing that is missing is for sigwaitinfo to be able to dequeue another process' signals, which is where the shared signal queue would come in.
> If you have a magic aio descriptor, how does the task process read > signals from it and stop?
I was looking at this as a way of dequeueing signals from the other process. The task process would have the signal queued and wake up the kernel process as happens now. The kernel process would have /proc/<task-pid>/sigqueue or something opened and would read siginfos from it. Those would then be dequeued from the task process.
This almost suffices for getting page fault information, except that, for some reason, siginfo doesn't say whether the faulting access was a read or a write.
And now that I'm thinking about it, aio doesn't really come into it. This would be strictly synchronous.
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/
| |