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.
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers