On Fri, Dec 15, 2006 at 10:14:06AM -0500, Alan Stern wrote: > On Fri, 15 Dec 2006, Christoph Hellwig wrote: > > > > Are signals the best available mechanism to request that a thread > > > stop that can exit on it's own. > > > > Defintly not. signals should be avoided in kernel threads at all > > cost. > > I have a driver that spawns a kernel thread (using kthread_create) which > does I/O by calling vfs_write and vfs_read. It relies on signals to > interrupt the I/O activity when necessary. Maybe this isn't a good way of > doing things, but I couldn't think of anything better. 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. > 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.
