Christoph Hellwig <hch@infradead.org> writes:

> Given that we have no other way to interrupt I/O then signals at those
> lower level I don't see a way around the singals if you stick to that
> higher level design.

It isn't hard to either modify signal_pending or the place where the
signal pending checks are to terminate things.

>> P.S.: What is the reason for saying "signals should be avoided in kernel
>> threads at all cost"?
>
> The probem with signals is that they can come from various sources, most
> notably from random kill commands issues from userland.  This defeats
> the notion of a fixed thread lifetime under control of the owning module.
> Of course this issue doesn't exist for you above useage where you'd
> hopefully avoid allowing signals that could terminate the thread.

Right unless you can get a state where user space is not allowed to send
signals but the kernel is.  But still reusing the concept if it doesn't quite
fit sounds like a definition mess.

Eric



_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers