On Fri, Jul 20, 2018 at 12:05:33PM -0700, Gé Weijers wrote:
> If Lua is embedded in a larger program that uses files or other types of
> resources elsewhere you end up having to call the emergency Lua GC from who
> knows where in the code. This may be a 3rd party library, or even a system
> shared library/DLL that you have no control over. A failure to allocate a
> file handle somewhere deep in library code may be unrecoverable.
The same applies to malloc failure. Should Lua also not bother invoking the
emergency collector when malloc fails?
Poor library QoI doesn't justify crippling the runtime or better written
libraries. Rather, the feature should stand on its own merits.
If 'malloc' fails (or you run out of file handles) just when a program is trying to open a file 'fopen' will in all likelihood fail, and return NULL.
This code is from liolib.c:
p->f = fopen(fname, mode);
if (p->f == NULL)
luaL_error(L, "cannot open file '%s' (%s)", fname, strerror(errno));
The emergency garbage collector is not going to help there. This would require modifying the Lua interpreter to add a recovery loop around every library call that could potentially fail because you run out of memory (or file handles). Unless that's done for 100% of calls that can fail (inside and outside the interpreter) your code can fail in unexpected ways.
BTW: on some systems 'malloc' doesn't fail, but a (possibly unrelated) program is killed to free up resources (look up the Linux kernel's "oom kiiler").
A feature that works most of the time just makes failures less likely, which increases the risk of problems going undetected long enough that broken code gets deployed. I like programs that fail early, and fail deterministically if they have any flaws. I hope that such a feature is made optional.
So for me: +1 on the "local scoped" proposal, -1 on the "let's try the garbage collector if things fail" idea.
