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

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