Re: Question about to-be-closed methods

[Dibyendu Majumdar <mobile@...>]

On Tue, 21 Jul 2020 at 17:58, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > It doesn't really make sense to me, but I am sure there is a good
> > reason for it.
>
> I already explained the reason. If you think it is not a good one, too
> bad; it is the only one. Once more: The call can fail due to lack of
> resources, but there is a good chance that the error itself will free
> those resources (e.g., stack space); so, the next call can succeed where
> the previous one failed. The option would be not to repeat the call, and
> therefore not to close whatever should be closed.

I understood the above. But I do not understand the details, and also
the bigger picture.
When you say 'due to lack of resources' - do you mean a scenario like
failure in malloc()?
If so:

a) In my opinion if malloc() fails all bets should be off - it is very
rare that a program can recover after a malloc failure. In my
experience a program usually cannot recover after a malloc failure in
the real world - because it probably implies failure in multiple
parts, not just Lua. Of course I do not suggest Lua should invoke
abort or exit. Instead Lua immediately return to calling routine with
an error code and the Lua State should be marked 'dead'.

b) What guarantees does Lua try to provide? Is it that every malloc
failure will be followed by GC followed by a retry? If not then why
try in this case?

'It doesn't make sense to me' is my bad way of saying that perhaps the
attempt to recover from certain errors is pointless.

>
> Note that, if the close method is error-proof, this is entirely
> a non issue.
>

Of course. In general it is a bad idea to throw errors from
'destructors' or 'finalizers'.

>
> > I was trying to figure out where in the code there is a
> > retry logic - but it isn't obvious. So it is a side effect of the
> > error handling I assume?
>
> The upvalue is removed from the open list only after the call. If
> there is an error, that sequence is interrupted, and the upvalue
> is not removed from the list. It would be easy to remove it
> before the call, if we preferred not to do the call again.
>

Thank you - I think you mean this commit:
https://github.com/lua/lua/commit/c220b0a5d099372e58e517b9f13eaa7bb0bec45c
?

I did try reverting the commit but it caused some failure in the
tests. But that was just my initial look - I will look deeper.

Regards
Dibyendu