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

[Francisco Olarte <folarte@...>]

Roberto:

On Fri, Jun 26, 2020 at 7:56 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> Probably it is not by chance that C++ does not call destructors for
> objects in the stack when os.exit is called.

For what I've been reading in the thread many people are not familiar
with C/C++ exit(3), so they seem to think exit is the recommended way
to get of the program.

One think, on the parallels between c** std:exit / lua
os.exit(x,true), i.e., closing the state.

We do not have atexit, but this is easy to do with a module and a
proxy, so not really needed.

C++, IIRC, destroys globals when exit() is called. os.exit(x,true)
closes the states, which is documented as "Destroys all objects in the
given Lua state (calling the corresponding garbage-collection
metamethods, if any)". I've always assumed this means ALL, I mean,
including objects referenced by local vars in modules, main thread
call stack and potentially suspended threads call stack. Is this
correct? ( I do not use exit but use lua_close profusely in embeded,
and have had not problem with missing __gc calls, but I'd like to know
if there is some corner case which I've not seen in the docs ( no
loops, resurrections or fancy things done in my code, but I'm in the
middle of a project which may call for destroying with suspended
threads, which I normally never do ) )

( note, I'm talking __gc, not __close, but my objects normally end up
calling and idempotent close() method anyway, which I call in the
normal flow, pretend to catch via toclose with 5.4 ( and avoid some
ugly xpcalls ), and will rely in __gc calling just for some serious
errors which warrant state destruction ).

Francisco Olarte.