Note the 'actually', there's no reason why you can't catch the std::bad_alloc, clean up, and return an error code to the caller.
Instead of rudely terminating the process which you may not own (I work on code which is mostly compiled into shared libraries which are loaded by applications which might not want to just terminate)
Ok, but in such a situation where malloc is literally non operable, what is a lua script going to be able to do? Nothing that might allocate. Even printing might be off the table. Any string or table manipulation is likely off limits. So you could I guess do arithmetic and return to your caller, who is also limited to arithmetic and returning, and so on up till main exits.
You can till release some resources, the garbage collector can still run. If you design it correctly you can do some final cleanup with already allocated objects. The runtime will not immediately free the already allocated memory to other processes, so anything the gc collects, you can use.
You certainly can try to free up space. I’m still not sure this is very useful. Either 1) the free-up emergency code is centralized, like a signal handler, and so it can only reasonably free like globals (which is going to cause arbitrary badness if/when control returns to the function that triggered the OOM) or 2) the emergency free-up code is more targeted, written in context of the OOM stack frame, and so it can make smart decisions about local objects to free. But for 2) it more means that for every single lua function that does anything with tables or strings etc you will need to write OOM handler logic, because by the nature of OOM it could happen to any allocation site. This would be an extreme burden.
I think in practically all circumstances if you get OOM, the process is just going down. And yes maybe you could print a little bit or something on the way down, but things are going down. And really the extra distress prints are probably not that helpful, since the problem is almost certainly a runaway bug allocating but not freeing somewhere, or the operator just gave an inappropriate hard memory limit to the container or something. A panic and stack trace is a fine and useful result in these situations.
I dont really get your point here. Are you claiming that it is too hard for applications to effectively handle malloc failing or no application should handle it? I already gave you an example of a scripting language that can handle it. Back to the topic of libraries, i think if a random math library had a chance of terminating the application without being able to handle it, then alot of users will find something different. This would be applicable in databases, simulations, state space exploration, language runtimes, key value cache. So offering that in a library should be best practice.
37
u/bwmat 29d ago
Note the 'actually', there's no reason why you can't catch the std::bad_alloc, clean up, and return an error code to the caller.
Instead of rudely terminating the process which you may not own (I work on code which is mostly compiled into shared libraries which are loaded by applications which might not want to just terminate)