| |||||||||||||
Now what about shutdown?Now what about shutdown?Posted Sep 22, 2008 22:48 UTC (Mon) by drag (subscriber, #31333)In reply to: Now what about shutdown? by Felix_the_Mac Parent article: LPC: Booting Linux in five seconds
Well if the applications are designed correctly then you can reduce the shutdown time to a few msec.
So the applications should be designed that at any time they can have the power cut and not lose data. You could have a 'shutdown' thread in the kernel that does the equivalent of (in psuedo-shell):
killall * && sync && acpi-poweroff
----------
For example; Say your editing a file and Vim caught a shutdown message then it wouldn't bother you with the details. It would simply double check that the last change you've made was committed to a temporary file on disk (which should of already been done if you were gone long enough to navigate to the shutdown button) and just die.
Next time you start up Vim you go right back to your edit. It does this mostly already.
I can send a killall -9 epiphany-browser and when I open the browser again it just starts me off were it left off. That's what it does now.
Similar things for OO.org and most other decent applications that I use. They don't need some complicated shutdown procedure.. just tell them to die, and then pull the power.
(Log in to post comments)
Just crash. Posted Sep 23, 2008 1:16 UTC (Tue) by dmarti (subscriber, #11625) [Link] Val Henson did a related LWN piece on Crash-only software. You have to write crash recovery anyway, so why not "crash" every time?
Now what about shutdown? Posted Sep 23, 2008 1:16 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Val Henson wrote an article about that for LWN: Link.The observation was that it often takes less time to crash and restart a program than it does to shut it down cleanly. So why not always crash it?
Now what about shutdown? Posted Sep 23, 2008 7:31 UTC (Tue) by nix (subscriber, #2304) [Link]
Because programs that crash are not necessarily in a consistent state, so
crash recovery can fail where ordinary bootups do not. (Of course, if you can make crash recovery reliable with something like application-level journalling, your point stands, unless like databases the post-crash bootup is really expensive. But that's probably a rare case.)
Other fun features for "crashable" apps Posted Sep 25, 2008 14:59 UTC (Thu) by dmarti (subscriber, #11625) [Link] Programs that come back in a messed-up state after a crash make baby Jesus cry. The vi clone "elvis" had good recovery very early, and we have enough disk space now to do it even for very large media files.A user actions log that an app could replay might have other uses, too. Of course there's deep undo and bug reporting, and automatic macro writing by identifying common steps might be useful. There was even a legal case a few years ago where a composer couldn't prove he had created a certain audio file, because he couldn't put the sliders of his GUI audio app on the exact right pixel.
|
|||||||||||||