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

[Jeff Dike]

[e-mail] 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