[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Question about to-be-closed methods
- From: Dibyendu Majumdar <mobile@...>
- Date: Tue, 21 Jul 2020 21:56:53 +0100
On Tue, 21 Jul 2020 at 21:09, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> As hinted in the message ("stack space"), the paradigmatic scenario
> is stack overflow. When Lua tries to call the close method, or when
> the close method tries to call an auxiliar function, there is a stack
> overflow, that is, the maximum number of calls allowed by Lua (or the
> maximum number of stack slots in use) is exceeded. In this case, the
> error will make Lua jumps out of at least one function, opening space
> for the close method.
Unfortunately stack overflow is an ambiguous term; because Lua stack
is on the heap, so it can only be heap failure.
The issue with maximum number of calls - I assume that this is a new
concern with Lua 5.4 due to use of C stack for calling Lua functions?
I am curious regarding the reasons for this change in the function
calling approach.
>
> But also we do not have such a grim view of memory allocation failures.
> Often the program is doing one particular task that demands lots of
> memory. Once that task is aborted, memory is back to normal levels and
> the program can continue doing other tasks. (As an analogy, you should
> not need to restart your computer if a process is killed by lack of
> memory.)
>
It is probably an imperfect analogy if you consider Lua as an embedded
language, where it is not the main program. There was a talk several
years ago by a Google engineer that said essentially there is no point
trying to recover after a memory failure. Fail fast is often a better
approach - because trying to recover in that scenario could cause more
damage because of further failures.
Regards
Dibyendu