Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
This is fantastic, it really throws down the gauntlet to every distribution.
Don't miss the video that Arjan has posted on youtube.
If we can boot in 5 seconds surely we should be able to shutdown in less?
Now what about shutdown?
Posted Sep 22, 2008 22:48 UTC (Mon) by drag (subscriber, #31333)
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.
Posted Sep 23, 2008 1:16 UTC (Tue) by dmarti (subscriber, #11625)
Posted Sep 23, 2008 1:16 UTC (Tue) by JoeBuck (subscriber, #2330)
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?
Posted Sep 23, 2008 7:31 UTC (Tue) by nix (subscriber, #2304)
Other fun features for "crashable" apps
Posted Sep 25, 2008 14:59 UTC (Thu) by dmarti (subscriber, #11625)
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.
Posted Sep 23, 2008 3:11 UTC (Tue) by arjan (subscriber, #36785)
Posted Sep 25, 2008 15:13 UTC (Thu) by dmarti (subscriber, #11625)
Posted Sep 26, 2008 2:24 UTC (Fri) by njs (guest, #40338)
IIRC emacs (used to?) do this by default, and until I disabled that it was unusable on a laptop, because hitting C-x C-s blocked everything for a few seconds waiting for the drive to spin up. ELISP SMASH
When is "save" really "maybe save"?
Posted Sep 26, 2008 15:05 UTC (Fri) by dmarti (subscriber, #11625)
(And you could always do the fsync in a separate thread or process, so the app is responsive again.)
Posted Sep 26, 2008 21:43 UTC (Fri) by njs (guest, #40338)
If the goal is to reach a point where we can throw away a lot of data instead of flushing it to disk at shutdown, then this approach is making a classic mistake: it's trying to mark everything that *does* need to go to disk, and hoping that eventually everything will be marked and we'll be able to flip the switch and throw everything else away. The better approach is to mark stuff that isn't important, like some fcntl to request "power-loss semantics" for writes to some file; then you could get some win immediately, and expand it incrementally over time.
I doubt this is easy or important enough to actually get the coordinated effort needed to implement it, but that's how I'd do it...
Posted Sep 23, 2008 17:09 UTC (Tue) by s0f4r (guest, #52284)
We so try to send a sync() as early as we possibly can to the system to remove some of this load, which seem to help.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds