> >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"?
Hmm. I assume the main reason is the extra bookkeeping overhead you
describe. As long as the process exists, it has an associated state,
that basically says where it is blocking. If you really killed the
process, you would have to kind of "shadow" that information to wait
for the operation to complete.
If you just marked it as killed, it is basically a kind of "pre-Zombie",
that is just used to hold that completion information.
Also from an accounting point-of-view, it might even be considered good,
that the connection between the process and the blocked ressource persists.
> Is it that the device is writting into process memory directly?
This is normally not the case. Stuff like DMA goes through driver buffers
usually. Data from RAWIO devices seems to be an exception.
> 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?
Uh - that's pretty hard.
Basically that would boil down to "spawing" a pseudo-process from the kernel
that would work as a placeholder for the original killed process. No gain
IMHO.
> >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.
Well ... I thought about the device drivers. They usually have (like they
have a rough estimate, that rewinding a tape might take long). However
in a layered scheme this gets more complicated, right.
> On the other hand, whatever is doing the IO can tell how long something
> should take.
You mean the application ? No. I don't think it has an idea. Say it outputs
on stdout. It has no idea where that is connected. Might be a 1200 baud
serial connection, might be a harddisk, might be /dev/null ...
> >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.
> 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?
_I_ don't. But look at everyone else. Look at netscape, look at about any
Windows program, ...
Yes, I would start an IO-thread/process, but who else would ...
> But for a major app, such as a graphical backup system, you have your
> graphic thread do the work of talking to the user,
Right. This is good design. But who actually writes good code ? :-(.
> Yes, a graphical backup application can ack a console switch.
Yes, but again is that good, that it absolutely _must_ ? No escape other
than killing it with SysRq ? I'd like a "forced switch" that will switch
no matter if acked and block the application as soon as it tries to
access a noe unavailable ressource.
But because we will probably never get that into the kernel, I'll live with
acked switches ...
> 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.
Ouch - you say it kind of "blocks" on displaying submenus ? And then of
course activates large ressources to restore the underlying background ?
> 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.
Yeah. I hate it, when you click on a displayed button and nothing happens
within a reasonable amount of time. If at least the button would be animated
at that time, I'd know it was recognized and happily wait for completion.
Something as simple as instantly "down"-ing the button when it was pressed
and "up"-ing it again, when the operation completed would allow me to
have a much better view of what is going on.
> In browsers, this can mean that the "stop" button isn't even enabled
> while some pages are loading.
Happens not only under Win ...
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
