On Wed, 3 Jan 2007, Eric W. Biederman wrote: > >> 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. > > > > In my case the situation is exactly the reverse: I _want_ to allow signals > > to terminate the thread (as well as allowing signals to interrupt I/O). I should have been clearer here. Signals don't terminate the thread; they merely notify it to clean up and terminate itself. > > The reason is simple enough. At system shutdown, if the thread isn't > > terminated then it would continue to own an open file, preventing that > > file's filesystem from being unmounted cleanly. Since people should be > > able to unmount their disks during shutdown without having to unload > > drivers first, the simplest solution is to allow the thread to respond to > > the TERM signal normally sent by the shutdown scripts. > > > > Since the thread is owned by the kernel, random kill commands won't have > > any bad effect. Only kill commands sent by the superuser can terminate > > the thread. > > > > Why in the world would a thread hold a file open for an indeterminate duration? > That seems very wrong. The thread uses the file to provide backing storage. Kind of like the loop driver, except that my driver uses a higher-level interface into the VFS than the loop driver does, for greater simplicity. You wouldn't say that what the loop driver does is wrong, would you? > I can just about understand reading a firmware file or something like that > and close the file afterwards. But unless you are worrying about a very small > window I think we have a problem here. I don't follow. Why do you think there's a problem? Alan Stern
