>
>> > > Ever see a process that survives kill -9?
>> I've seen programs survive it. As far as I can tell, they
>> are waiting for an IO operation to complete, and it
>> has been lost (or perhaps an NFS hardmount?)
>
>Yes. This is possible. They are in uninterruptible sleep, then.
>This basically means a kernel call is hanging, which is uninterruptible
>(i.e. the kernel is of the optionion this request _has_ to complete before
>anything else happens).
Ok, why does the kernel think this? Why can't the kernel simply say
"ok processes, you're out" now, and when the IO operation finishes,
say "Thank you device, but I no longer need it"?
Is it that the device is writting into process memory directly?
Then can't the kernel track "This block of memory is owned by
two entities", and when one is killed, de-allocate all the unshared
memory?
Similar with file descriptors, if the system is sharing those at
the low level?
(would you believe I've been working with Unix, and seeing this
kill -9 survival, since 1983, and never thought to ask this
question?)
>There is nothing one can do about that. Basically it is a problem in the
>kernel, if the program stays in uninterruptible sleep for excessive amounts
>of time (say >10 minutes). The kernel has to give the IO operation enough
>time to complete, but there has to be some timeout.
For The Record: This should *NEVER* be a kernel decision as to "how
long is too long". The kernel has no idea how long is too long.
On the other hand, whatever is doing the IO can tell how long something
should take.
Simply have everything report back to the kernel how long it's share
should take, have the kernel add up what every sub-portion says is
the timeout, and maybe stick a little fluff in that the kernel can
compute (based on things like system load, or whatnot), and then use
that as the timeout.
Example: The file IO routines might know how long their IO should take.
The next layer underneath might be a replication layer and know that
it will take more time to check with the file replicants. And a
farther down physical disk IO layer might know "Hey, this drive is spun
down -- give me 10 seconds to safely re-spin".
If there's an NFS client somewhere in the stack, then it might
get to be a real large time estimate, especially if the NFS protocol
is ever extended to where the server can give a fast response of "this
operation will take excessive time" or if the system can indicate
how slow a communications link exists (NFS over a 33.6 modem
will be slow, etc.) Just for a quick thought, you might just
assume twice the "hard IO failure delay" timeout.
>This state is also one of the major reasons, why I think cooperative console
>switching is a bad idea. A graphical backup application would not be able to
>ack a console switch while rewinding a tape ... GRR.
>
>CU, Andy
Sure it can.
What, do you mean to tell me that you routinly write programs where
the user interface is blocked by long IO operations?
As a quick hack (shell scripts, etc), sticking "mt rewind" in there
might make sense -- I have yet to figure out how to write a shell
script that has good and convinient ways to wait for specific
children, alarm timeouts, or interrupts from the user and respond
to all of them. But for a major app, such as a graphical backup
system, you have your graphic thread do the work of talking to the
user, determining what needs to be backed up, etc -- and then hand
that to another thread that does no graphical or console IO, and
the main thread talks to the graphics server/user for feedback.
Yes, a graphical backup application can ack a console switch.
Because the thread that is blocking for the rewind operation to
finish is not the thread that listens to the graphics server.
Since there seems to be a fair number of graphical design people on
this list, let me give you some more examples of this (my pet peeves):
1. Going through a menu (apple Mac 8): When I'm dragging my mouse
down a menu, if the GUI/UI says "he just dragged over something
that has a sublist -- lets build that sublist and ignore any further
mouse moves until after the list is built and displayed", then it
shows this bad behavior. If I move OFF that list item, I may want
to select the non-list item underneath it. And that operation
(building the next level of display) is surpisingly SLOW, especially
if the disk has been spun down, the VM system is high on swap usage,
or the OS is hosted under another.
2. User feedback re-ordering (win95): Windows makes the [appropriate
in the age of 64K 8086, inappropriate today] assumption that any
user feedback display operations can wait until the program's
message queue is empty. In browsers, this can mean that the "stop"
button isn't even enabled while some pages are loading.
(those are just what comes to the top of my head right now).
