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

[Udo A. Steinberg]

On Wed, 07 Aug 2002 22:14:42 -0500
Jeff Dike <[e-mail]> wrote:
> 
> Not really.  What we really want is for signals not to be delivered at all.
> That's why the ptrace signal annulling capability is nice.
> 
> I'm not sure if this makes any sense, but coupling the new aio mechanism with
> something that queues up siginfos might be interesting.  It would be a magic
> descriptor that would feed you signals when you read it.
> 
> Is that at all sane?

I know that we're trying to avoid signal handlers, because they are expensive.
But the signal would not need to be delivered in the task. We need a mechanism to
stop the task and force it into kernel. 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.

When running in a kernel context, you actually need to deliver SIGIO in order
to interrupt the current context.

If you have a magic aio descriptor, how does the task process read signals
from it and stop?

-Udo.