Re: RFE: refman - adding mention of os.exit not closing variables with default arguments.

[Lorenzo Donati <lorenzodonatibz@...>]

On 24/06/2020 03:43, Gé Weijers wrote:
> > To-be-closed variables are a new feature and a safety- and data
> > integrity-related one so, IMO, users should be given extremely
> > clear information on what are the guarantees of the new mechanisms,
> > otherwise they could get a false sense of security and put nasty
> > bugs in their program.
>
> Another trap you can fall into is to put a local ... <close>
> variable inside a coroutine. There are a number of problems with
> that:
>
> - you have to explicitly call coroutine.close(thread) to do the
> variable cleanup if the coroutine is suspended (has yielded). -
> coroutine.close does not work on threads that are not suspended or
> dead,  i.e. threads that are waiting for coroutine.resume to return.
> - if you call os.exit(<code>, true) from a coroutine no __close
> metamethods will be called in any thread, not even the main one.

I'm not a big expert of coroutines, so I can't comment on the nuances of
the subject. Anyway it seems that this new "to-be-closed" variables
mechanism makes working with coroutines more awkward, at least if 
someone wants to use TBC vars in coroutines.

> The behavior of os.exit is in my opinion a bit inconsistent, it
> unwinds the stack and closes to-be-closed variables in the main
> thread, but only if you call it from that main thread, and it does
> not do anything to other coroutines.

I wonder whether the whole mechanism is amenable of improvement in these
areas (i.e. guaranteed closing despite any mechanism that makes a
program terminate in orderly fashion) or there is a fundamental flaw in
the design that makes it impossible to handle some specific cases.

Although I've always wanted a clean, language-supported way to do RAII
in Lua, I'm still quite unsure if the current mechanism, as it is now,
is worth the hassle.

I didn't follow the 5.4 development closely, but it seems that the
mechanism doesn't provide unique features. I mean, you can still do RAII
without it, it just needs more programming discipline.

The whole point of the mechanism, as I see it, is that you could do RAII
in a much simpler way. But if it introduces other, subtler, issues then
I'm beginning to question its usefulness.

To be clearer: now (Lua 5.3) I can do RAII using more discipline and
sprinkling error handling code in key parts of the code. This approach 
adds clutter to the code but the error handling code is explicit and clear.

In 5.4 I could reduce clutter by using TBC vars, but then I must add
some extra checks or mechanism to handle those exceptional cases when
TBC vars mechanism "fails" (and coroutine users are especially worse
off, it seems). Moreover, the new syntax is not that great.

All in all, I'm starting to think that the mechanism is not
well-polished yet. At least not enough to warrant a shift of paradigm.
But maybe I'm missing something.

I think I will stick to the older way of doing this. At least I know
better how things can go wrong. So probably I won't upgrade to 5.4 yet,
since the only new features that could made me switch were TBC vars.
Const vars are cool, but all by themselves are not groundbreaking enough.

I'll probably wait and see what other users think of the new features 
once they begin putting them to good use.


> Gé



-- Lorenzo