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.
-
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/