5 ms·

Users are aware things stop working when memory is exhausted. As a user I am ok with this. I don't let my memory end and would prefer that the application work

Users are aware things stop working when memory is exhausted. As a user I am ok with this. I don't let my memory end and would prefer that the application worked reliably while there is still memory. What I don't like is applications trying to pretend nothing happened but then doing some strange shit. I have seen, for example, applications using 100% cpu after they hit OOM. Yes they survived. No, it is not user friendly.

SigmundA 5y ago
Why would users be aware what happened? Did you tell them? This is a very reliable and easy for the user and other developers to understand. try { image = LoadImage(path); } catch(OutOfMemoryException e) { Msgbox("Cannot load image it is too large for available memory"); } That is way more friendly than a program crash and allow the user to try again perhaps with a smaller version of the image because they accidentally picked the high res version or something. Either way you may get 100% CPU as the program crashes and memory gets reclaimed, or the program continues to run and the garbage collector reclaims.
- XorNot 5y ago
  Although you've encoded the whole problem right there: do you even have enough memory to setup a MsgBox widget or whatever that is?
  - SigmundA 5y ago
    In a GC'd language which is what I am used to, the GC will pause execution and reclaim on the next allocate if there isn't any available memory cleaning up whatever was allocated on the attempted image load. After that if there is still not enough memory for the simple message box then you have an uncaught exception and the program crashes and you're just back to the no catch approach, nothing lost. Most likely though there will be enough memory for the message and you have a much more friendly result. I have used this approach before and it is way way more friendly then a crash with users potentially losing work because they accidentally picked the wrong file.
    - lmilcin 5y ago
      > After that if there is still not enough memory for the simple message box (...) That's exactly the point. Once memory is exhausted, you can't take any action reliably. You don't build reliable applications by making mechanisms like: "ok, if memory ends lets design it to show a box to the user, we have 50% chance this succeeds". It would be better to wrap your application in a script that detects when the application quit and only then shows a message to the user. People designing things like you drive me crazy. They come up with a huge number of contingencies that just don't work in practice when push comes to shove. Stuck in a loop trying to show a widget, using 100% of CPU and preventing me to do any action? I prefer simpler mechanisms that work reliably.
      - dnautics 5y ago
        All critical paths, should be allocated on application start, and you never have to worry about that.
        lmilcin 5y ago
        This is the kind of advice that I put in a category of "easier said than done". The trouble is that you may not know beforehand what exactly is going to be needed. And you might need maybe a library call and the library does dynamic allocation in it and you either have no idea about it (until you find out the hard way) or no way to help it. So in the end maybe you can take some extremely simple action like writing something to log or show a widget, but that's about it.
        dnautics 5y ago
        Just code as normal and when you run into a problem, reassign the default allocator for the struct/object? Not possible for many PLs, hard for some but basically trivial (1 LOC per struct/object) for others. Some PLs come with test suites that give you a failing allocator, so you can even easily test to make sure this looping condition resolves sanely.
      - SigmundA 5y ago
  - dnautics 5y ago
    Preallocate that? If it's modal, you should never have more than one, and the allocator associated with the msgbox should know to use that scratch space instead of fetching new memory. This is nontrivial in several PLs.

SigmundA 5y ago

Why would users be aware what happened? Did you tell them? This is a very reliable and easy for the user and other developers to understand. try { image = LoadImage(path); } catch(OutOfMemoryException e) { Msgbox("Cannot load image it is too large for available memory"); } That is way more friendly than a program crash and allow the user to try again perhaps with a smaller version of the image because they accidentally picked the high res version or something. Either way you may get 100% CPU as the program crashes and memory gets reclaimed, or the program continues to run and the garbage collector reclaims.

XorNot 5y ago
Although you've encoded the whole problem right there: do you even have enough memory to setup a MsgBox widget or whatever that is?
- SigmundA 5y ago
  In a GC'd language which is what I am used to, the GC will pause execution and reclaim on the next allocate if there isn't any available memory cleaning up whatever was allocated on the attempted image load. After that if there is still not enough memory for the simple message box then you have an uncaught exception and the program crashes and you're just back to the no catch approach, nothing lost. Most likely though there will be enough memory for the message and you have a much more friendly result. I have used this approach before and it is way way more friendly then a crash with users potentially losing work because they accidentally picked the wrong file.
  - lmilcin 5y ago
    > After that if there is still not enough memory for the simple message box (...) That's exactly the point. Once memory is exhausted, you can't take any action reliably. You don't build reliable applications by making mechanisms like: "ok, if memory ends lets design it to show a box to the user, we have 50% chance this succeeds". It would be better to wrap your application in a script that detects when the application quit and only then shows a message to the user. People designing things like you drive me crazy. They come up with a huge number of contingencies that just don't work in practice when push comes to shove. Stuck in a loop trying to show a widget, using 100% of CPU and preventing me to do any action? I prefer simpler mechanisms that work reliably.
    - dnautics 5y ago
      All critical paths, should be allocated on application start, and you never have to worry about that.
      - lmilcin 5y ago
        This is the kind of advice that I put in a category of "easier said than done". The trouble is that you may not know beforehand what exactly is going to be needed. And you might need maybe a library call and the library does dynamic allocation in it and you either have no idea about it (until you find out the hard way) or no way to help it. So in the end maybe you can take some extremely simple action like writing something to log or show a widget, but that's about it.
        dnautics 5y ago
        Just code as normal and when you run into a problem, reassign the default allocator for the struct/object? Not possible for many PLs, hard for some but basically trivial (1 LOC per struct/object) for others. Some PLs come with test suites that give you a failing allocator, so you can even easily test to make sure this looping condition resolves sanely.
    - SigmundA 5y ago
- dnautics 5y ago
  Preallocate that? If it's modal, you should never have more than one, and the allocator associated with the msgbox should know to use that scratch space instead of fetching new memory. This is nontrivial in several PLs.