3 ms·

http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm So Herb Sutter mostly agrees with your view, but my question is a corolla

http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm So Herb Sutter mostly agrees with your view, but my question is a corollary, and something he touches on: how do you keep going if you stop what you were doing? The process of recovering is not straightforward, and if you have threads running, that process is utter chaos, if not outright impossible in some languages. Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Either way, the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first place -- which, incidentally, leaves the user stuck in exactly the same place as if your application aborted. The big idea here is that the OOM condition may not be because of your application.

quotemstr 11y ago
> how do you keep going if you stop what you were doing You unwind. If you have threads, you reliably signal for them to stop (using resources you've set aside for the task), then you join the threads and continue unwinding. I think it's perfectly straightforward. > Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Most serious operating systems have a way to say "run this process in this special environment where it can't allocate more than X MB of memory". (Some examples are NT Job objects, FreeBSD jails, Linux cgroups, and plain old ulimit.) In this kind of environment, you can certainly run up against limits for your process without the system having been rendered unusable. > because the system is already hosed to the point where a small memory allocation will fail Absolutely not the case. Imagine a state where a 100MB allocation (e.g., for an image) might fail (say, due to virtual address space fragmentation), but a 10 byte allocation would work just fine. The same principle applies to system commit considered globally instead of virtual address space considered per-process. > the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first plac If that's the case, the application is just badly coded. Memory is not special. It's just another resource. If you can't keep track of resources and release them when they're unneeded (as they would be after an error), you're doing something wrong. > http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm That article is factually incorrect. Sutter claims that "On...Linux, memory allocation always succeeds. Full stop." That's false, as a ten-line C program that calls malloc in a loop can demonstrate. You eventually run out of address space, especially in a 32-bit process. (There's a very popular overwhelmingly 32-bit Linux distribution out there called Android. You may have heard of it.) Sutter also claims that on other operating systems, overcommit is configurable. It's in fact configurable under Linux too. Linux can run in sane, non-overcommitting mode.

quotemstr 11y ago

> how do you keep going if you stop what you were doing You unwind. If you have threads, you reliably signal for them to stop (using resources you've set aside for the task), then you join the threads and continue unwinding. I think it's perfectly straightforward. > Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Most serious operating systems have a way to say "run this process in this special environment where it can't allocate more than X MB of memory". (Some examples are NT Job objects, FreeBSD jails, Linux cgroups, and plain old ulimit.) In this kind of environment, you can certainly run up against limits for your process without the system having been rendered unusable. > because the system is already hosed to the point where a small memory allocation will fail Absolutely not the case. Imagine a state where a 100MB allocation (e.g., for an image) might fail (say, due to virtual address space fragmentation), but a 10 byte allocation would work just fine. The same principle applies to system commit considered globally instead of virtual address space considered per-process. > the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first plac If that's the case, the application is just badly coded. Memory is not special. It's just another resource. If you can't keep track of resources and release them when they're unneeded (as they would be after an error), you're doing something wrong. > http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm That article is factually incorrect. Sutter claims that "On...Linux, memory allocation always succeeds. Full stop." That's false, as a ten-line C program that calls malloc in a loop can demonstrate. You eventually run out of address space, especially in a 32-bit process. (There's a very popular overwhelmingly 32-bit Linux distribution out there called Android. You may have heard of it.) Sutter also claims that on other operating systems, overcommit is configurable. It's in fact configurable under Linux too. Linux can run in sane, non-overcommitting mode.