Christoph Hellwig <hch at 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
