On Fri, May 1, 2015 at 11:48 AM, Alex Williamson
<alex.williamson@xxxxxxxxxx> wrote:
>
> Ok. It seemed like useful behavior to be able to provide some response
> to the user in the event that a ->remove handler is blocked by a device
> in-use and the user attempts to abort the action.
Well, that kind of notification *might* be useful, but at the cost of
saying "somebody tried to send you a signal, so I am now telling you
about it, and then deleting that signal, and you'll never know what it
actually was"?
That's not useful, that's just wrong.
Now, what might in theory be useful - but I haven't actually seen
anybody do anything like that - is to start out with an interruptible
sleep, warn if you get interrupted, and then continue with an
un-interruptible sleep (leaving the signal active).
But even that sounds like a very special case, and I don't think
anything has ever done that.
In general, our signal handling falls into three distinct categories:
(a) interruptible (and you can cancel the operation and return "try again")
(b) killable (you can cancel the operation, knowing that the
requester will be killed and won't try again)
(c) uninterruptible
where that (b) tends to be a special case of an operation that
technically isn't really interruptible (because the ABI doesn't allow
for retrying or error returns), but knowing that the caller will never
see the error case because it's killed means that you can do it. The
classic example of that is an NFS mount that is mounted "nointr" - you
can't return EINTR for a read or a write (because that invalidates
POSIX) but you want to let SIGKILL just kill the process in the middle
when the network is hung.
Linus
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
