Quote:Original post by DoctorGlow
I'm more interested in correctness and consistency then saving few seconds on shutdown.
This depends on type of application. Memory is just part of the equation, there's also all other resources, such as file and socket handles, video and other media resources, and much more.
And there's something worse. If you hit pagefile, then deleting all the memory will need to reload all the data from disk just to free it.
If user hits shutdown, what you *need* to do is save anything that needs saving. Perhaps a document user is editing.
For games - exit might as well be immediate after [exit] is pressed. Just check if a save happens to be in progress.
As far as consistency goes - this isn't against it. Your application can still be fully consistent, and do all the nice cleanup/shutdown and RAII and all that for testing and debugging, but do the fast exit for release. This approach works for all applications, as long as you keep track of dirty state which needs to be fully committed.
Another problem is runaway/undefined behavior of code. While that might make application unresponsive, if the event loop remains alive, it would allow you to cleanly kill the application, whereas full cleanup would just hang.
Also, experience shows that due to various reasons, using System.exit() in Java is a good practice to avoid spurious java apps hanging around after they've shutdown, which is an incredibly common problem. Might as well call it after believing to have shutdown what is required.
In native apps, especially when dealing with complex resources or heavy use of hardware, obscure synchronization bugs will creep up.
Quote:IMHO, adhering and using good programming practices makes and teaches you to be a better programmer and that's for me is a big plus,
Good practices also involve real world issues, not academic purist approach. And applications hanging during and after shutdown are a real world problem.
Finally - almost all of CS and best practices is taught on infallible machines. RAM does cause faults, OS does mess up, GPU does perform incorrect calculations due to overheating, third-party API does break.... At least obey the user and simply exit when asked for.
Quote:regardless if it takes more code, longer to write and more reading at the beginning of your programming journey.
More code = bigger statistical chance of introducing a bug (programmer, hardware error, faulty unit test, disk fault, timing issue due to cache flushes, maintenance programmers, etc.).
Perfection is not when there is nothing to add, but when there is nothing left to take away.
Quote:Not all "resources" are like memory, and not all of them are automatically freed on program exit.
This is very true, especially with any kind of external storage (files, databases, ...).
But applications do crash, power does go out, OS does lock-up. So rather than assuming one can write perfect cleanup, make sure to have a recovery mechanism that will handle all this junk leftover data.
There are two sets. One covers the data you absolutely need to cleanup and preserve. The other is optional.
Since the number of problems in second set is effectively infinite, instead plan for the first one with absolute scrutiny. When something needs to be persisted, it is. When something needs to be cleaned up, make sure it is.
Counter example - savegame. User presses save, gets "ok", presses exit, game exits cleanly, OS crashes. Bummer, data still wasn't committed to disk, so the savegame will be corrupted.
Now assume other way: savegame is atomic, and doesn't return "ok" until it confirms data was written to disk completely and correctly. At that point, you might as well ExitProcess(). Nothing can go wrong.
This doesn't involve internal state management and leak prevention - it is about the important data that matters to user. If you can get that right, then you also solve the crash problems and other unexpected termination scenarios.
Same for servers. They *will* exit uncleanly. So instead, "crash" them yourself. Migrate data from one server to another, kill the original one along with the OS and do a hard reset. Obviously, you can try for clean shutdown first. This is one of reasons why PHP is so popular in practice - stateless + per-request startup/shutdown.
This last advice in particular may be controversial, but once you realize how many things can and do go wrong, it becomes easy to assume that prevention is always good, but having a perfect recovery plan is better.
One final point on quick shutdown - low power. Many battery powered devices out there, and most of them operate on really small persistent state. Trying to shut down hundreds of megabytes of data when only 40kb really need to be written is not really a benefit for the user.
[Edited by - Antheus on February 28, 2010 6:46:01 PM]