On 04/14/2012 04:11 PM, Alan Cox wrote:
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
When it leaves the system in an unstable state or where corruption could
follow. Far better then to leave that process stuck unless things sort
out.
But, drivers can also be reset. And resetting a driver should, in
theory, reset the hardware. So a system should never be left in an
unstable state. But, what if there are other requests pending of that
same hardware? The only alternative is to invalidate those requests and
issue an I/O error. But the app-handlers should catch these and deal
with them reasonably.
Then there's the question of what could require an infinite amount of
time for a driver to return? How long will a human wait? I can't think
of a request that isn't bounded by some physical time limit except for a
requested sleep alarm. And I can't think of a request that I'm willing
to wait on for 3 days. There really shouldn't be a "wait-forever" state
because that just means "wait until the user powers me off". I think
all states should be bounded. At least bounded from the standpoint of
returning to user-level for further action (either re-invocation of the
wait or exiting). Let the app-layer determine what to do if the lower
level can't do something - the app-layer is free to re-invoke the kernel
request.
Shane
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
