tag:blogger.com,1999:blog-203063759820106893.post3478188950153323423..comments2023-03-25T08:30:26.602-04:00Comments on A Moment of Zen: Worse is Better in the form of AutosaveJeffrey Stedfasthttp://www.blogger.com/profile/12271561115384429651noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-203063759820106893.post-50789197526595749252008-02-04T22:46:00.000-05:002008-02-04T22:46:00.000-05:00I agree apps shouldn't have to handle OOM. Well sa...I agree apps shouldn't have to handle OOM. Well said.<BR/><BR/>Now, there's this cute little feature in OSX where the desktop (Aqua) will basically tell you when you are about to run OOM, and I've seen several cases where apps would not crash, but just return an error. I don't know how they do it, nor do I care. But it's insanely useful and provides a true feeling of stability and elegance. Whatever this is, whatever the API, it can be done and has been done. Denying that is insanity.<BR/><BR/>Linux, or whatever *x desktop, just doesn't have that.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-83803945989608840372008-02-04T13:31:00.000-05:002008-02-04T13:31:00.000-05:00Raphael:As per point #1, yes, auto-save can be exp...Raphael:<BR/><BR/>As per point #1, yes, auto-save <I>can</I> be expensive (in terms of disk i/o), however, if your number 1 priority is never losing the user's data, then you have no other real choice: all the error checking in the world will not save your user's data if the power goes out, for example.<BR/><BR/>I'm not saying that error checking shouldn't <I>also</I> be done, but it is far from a reliable solution. Auto-save type solutions provide a much safer means of protecting your user's data... how often you invoke auto-save is up to you.<BR/><BR/>Just because you implement auto-save doesn't mean you can't <I>also</I> implement any emergency save in a signal handler. In fact, this is another excellent idea, however it <I>may</I> be too late once a signal is raised... particularly if that signal is a SIGSEGV.<BR/><BR/>My point was that it is 1) impractical to manually error check every malloc() call and do proper error handling, passing the error up the call stack in a large complex gui application because it is very error-prone and 2) it will never be able to handle all possible error conditions e.g. power outages, bugs in your own code, bugs in a library you built upon, or, heaven forbid, a bug in the hardware itself.<BR/><BR/>if (!(ptr = malloc (size))) {<BR/> /* handle error */<BR/>}<BR/><BR/>will never be an end-all fail-proof solution to never losing a user's data (even if the error condition is EMEM), no matter how much the idealists claim that it is because software (and the hardware it runs on) is made by humans, which means that it is, by definition, imperfect.<BR/><BR/>As per point #2... I'm on Novell's Mono team. Does that answer your question? :)<BR/><BR/>(Hint: Yes, I believe that there are better languages than C in which to implement large complex applications.)Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-43964319973905871942008-02-04T13:11:00.000-05:002008-02-04T13:11:00.000-05:00I agree with most of your comments and with the wa...I agree with most of your comments and with the way g_malloc() and friends are implemented in glib. However, I would like to make two comments:<BR/><BR/>First, implementing auto-save is considerably more expensive than implementing emergency saves. If the application that you are developing has to deal with large files or with very complex data structures, then saving the data on a regular basis can consume a lot of processing power and/or memory. In many cases, it is easier to implement emergency saves: save whatever can be saved just before crashing (like in a signal handler) but otherwise do not disturb the user with heavy background tasks. Alas, glib does not provide an easy way to catch all out-of-memory errors and then trigger the emergency saves. A SIGABRT handler is not an ideal solution because it could be triggered by other things than the out-of-memory condition. It would be nice to be able to register some kind of out-of-memory callback function without having to implement a whole set of wrapper functions with GMemVTable.<BR/><BR/>My second comment is about the way you describe the problem and the solution. Do you realize that it could also be read as a recommendation to switch to managed languages with proper exception handling? Errors happening deep in the code (including third-party libraries) can be caught with a try/catch block or similar constructs. So... are you suggesting that instead of using glib, we should all move to Java or C#? ;-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-22091354816561702542008-02-04T08:58:00.000-05:002008-02-04T08:58:00.000-05:00Bad thing is, it's hard (impossible, that is) to e...Bad thing is, it's hard (impossible, that is) to estimate how much memory you need for ui, or how much memory you could reserve for non-ui stuff. Say, you want to allocate gazillion bytes to keep a BigThing. You do g_try_malloc(), it succeeds, and then the application aborts when user opens a menu. And g_slice_alloc will abort on OOM unconditionally, and no emergency pools will help there.<BR/><BR/>But I can't imagine g_list_prepend() which could fail :)Yevgen Muntyanhttps://www.blogger.com/profile/01546220575080641486noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-32421989573914460312008-02-04T04:57:00.000-05:002008-02-04T04:57:00.000-05:00Agreed. Nobody really wants to check every return...Agreed. Nobody really wants to check every return from malloc(), and I dare say there are a lot of C programmers that don't even bother. <BR/><BR/>Besides, even if the ability to handle out-of-memory errors is something really vital to your application, I question the judgment of anyone who will dismiss the entire library based solely on the behaviour of g_malloc. It can be worked around.Simon Howardhttps://www.blogger.com/profile/00547759817975257387noreply@blogger.com