lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 30/05/2020 10:24, Sean Conner wrote:

It was thus said that the Great Lorenzo Donati once stated:

On 29/05/2020 22:57, Sean Conner wrote:

It was thus said that the Great Phil Leblanc once stated:

When os.exit() is called, by default the finalizer for <close>
variables is not executed. If the second (optional) argument to
os.exit() is true, then the Lua state is closed, and finalizers are
executed.


I didn't realize that!

  In Lua 5.1, os.exit() calls exit().  In fact, the function is quite short
and reproduced here:


[snip]


  The problem is that the Lua state isn't cleanly closed.  If one wants to
cleanly close the Lua state upon os.exit() in Lua 5.1, one would have to
register a cleanup function via atexit().  Something like this:


[snip]


  This may have been an oversight on the Lua team, but as they have always
stated, the lua exectuable has *always* been an example of how to embed Lua.
And on most modern systems (POSIX definitely, possibly Windows these days),
the operating system will reclaim any resources used by a process upon
shutdown *anyway*.


Interesting.


  This was rectified with Lua 5.2, but to remain compatible with Lua 5.1
code, they decided to add a parameter to os.exit() to indicate a clean
closing of the Lua state, so the function now looks like:


[snip]

  Why they decided to keep this level of backwards compatability when they
drastically changed how modules and global variables work between 5.1 and
5.2 is beyond me, especially when a workaround for Lua 5.1 (as illustrated
above) was available.


Yep, I remember the gist of that change, although I didn't know the 
implementation details.



  But we have what we have.


I agree (reluctantly) on maintaining the backwards compatibility, but
<close> finalizers are different things. I would find rather unexpected
for them non being called on exit.

  Technically speaking, they don't leave the scope.  The Lua VM doesn't know
that os.exit() actually leaves the scope (or rather, that it leaves the VM
entirely).  To the Lua VM, this:

	do
	  local x <close> = io.open("foobar")
	  os.clock(0)
	end -- now we leave scope, x is closed

and this:

	do
	  local x <close> = io.open("foobar")
	  os.exit(0)
	end -- now we leave scope, x is closed

are the "same"---a to-be-closed variable is created, a function (from the
'os' table) with one parameter is called, then the scope ends, so call
x:__close().


I didn't know that, interesting. I didn't follow the development of Lua 
5.4 closely. I would have guessed that any (non-emergency/non-fatal) 
mechanism that could force the VM to shut down, would force __close to 
be called. After all, that's the main application of RAII: ensure proper 
resource disposal in all cases (except "end-of-the-world" scenarios, of 
course).



  At least, I *think* this is the case---I haven't actually tested this, but
I think my reasoning is sound on this.


If one really wants NOT to call __close on exit, it would be better to
add another argument to exit (I know, ugly), or maybe define a new
behavior for exit when the second arg is a string, so that the string
specifies what to call or what not, e.g.:

os.exit( exit_code, 'noclose, nogc')

  I'm not sold on that.

Yes, I admit it's not particularly clean nor cute. And I don't like it 
too much, too. It's the first thing that came off the top of my head. 
Maybe someone could come up with something better.

Moreover, imagine the confusion when integrating different codebases,
which is not uncommon in Lua ecosystems, with all the different small
libraries out there.

If everyone had their own safeexit, with different signature and name, a
real hell!

  Is this a real problem, or a hypothetical problem?


More of an hypothetical one, but I've grown to be a very defensive 
programmer through the years. And I always try to work out the worst 
scenarios, at least based on past experiences.

__close is part of a safety mechanism. We have coped with its absence in 
other ways. The only advantage over the "old style" is that now you 
don't have to follow so rigid a discipline when you write your code, and 
the code is more elegant, since you could program your "finalization" 
routine upfront.

The only new mechanism is the /automatic/ call to __close in cases where 
coding disciplines is not enough, that is abnormal exits like exceptions 
and os.exit. If it doesn't work for exit BY DEFAULT, that's a big safety 
hole. You could force yourself to write os.exit(code, true) every time, 
but that's, again, coding discipline (which __close was meant to relax).


<rant>


Anyway, the manual should definitely point out this caveats more 
explicitly. Maybe I missed something, but there is no clear statement 
that __close WON'T be called on a normal os.exit() call.

To get that you should perform quite a convoluted inference: reading 
os.exit you should infer that a "Lua state" is something you need to 
know about (which is not a concept exposed to Lua side). Then you should 
dig into the C-Lua part of the manual and discover what a Lua state is 
and that when it is closed it will automatically call __close.
I.e. you must end up reading lua_close docs. And note that there is no 
direct link between __close docs and lua_close (OTOH there is a 
reference to lua_close in the GC section of the docs, end of 2.5.3).

Too much for a "pure" Lua programmer, IMO.


It's something of a pet peeve of mine to play the part of the "poor 
'pure' Lua programmer", although I can't define myself like that (even 
if I don't use Lua C API regularly, and I'm no C guru, I can understand 
what's happening under the hood).

I really think Lua should be more widespread, and a good ref man that 
can be used by motivated users to learn the language (without knowing a 
single line of C) is a mean to that end.

BTW, I think that's one of the selling point of Python, which is all the 
rage now. I know Roberto doesn't think like that, but I must say that 
if, when I started to learn Lua /using just the refman/, I hadn't known 
C/C++ I would have been scared away by just reading the docs of os.date 
that told me to go look for strftime to learn how to format a date in Lua.

Heck! What does it mean "C strftime" to a newbie?!? Even that name 
'strftime' is not a comprehensible name, but a bunch of letters spliced 
together (thank you, C)! At least a link to, say cppreference.com could 
be a good hint.

I know the mantra "go buy PiL to be hand-held", but that's for people 
who have some money. Lots of people picked up Python because of the 
combination of (a) Completely free and open (Lua has it), (b) lots of 
good libraries ready to use with no hassle (Lua is far from that stage) 
(c) Good FREE docs for newbies all in one place (Lua is not there).
Moreover, in the age of the Internet, having to pay for tech docs is a 
bad marketing move.

There is a reason why big hardware corporations (e.g. chip 
manufacturers) put their datasheet online for free (and lots of 
application notes that are university book level quality): if people 
don't know your technology, they won't buy it and will look for 
companies that won't hold critical information before you buy.
I know of hardware/firmware engineers that get pissed off if to download 
a datasheet they even have to free-register with the company!

I know that for an open-source, free project the analogy is a bit 
stretched: you don't "buy" anything from Lua Team.
But, anyway, the underlying market forces are just the same: people 
won't pay for information they don't know it will be useful for them. 
Especially if they have a free alternative; even if it's a /worse/ 
alternative. Lots of time people choose known worse alternative over 
good ones that they know little about. It's psychology, babe! If you 
want people to use Lua, you should strive to convince them it's good for 
them. And C /is/ scary (for good reasons).

And having more people using the language is also a marketing booster, 
because then it becomes easier for a firm to adopt the technology 
because there are lots of programmers around (and you are not locked-in 
to some people you can't hope to replace, if the need arise). And if 
more firms are going to use the language, then it becomes more enticing 
for newbies wanting to dust-off their CVs learning that tech, and so on.

Moreover, think of the best (in the sense of bigger quantitatively) 
marketing booster Lua has nowadays, people modding games using embedded 
Lua. They are kiddies or youngsters that really don't care about Lua in 
itself, mostly. They like modding their game platform and they learn Lua 
in the process. Will they become developers? Maybe, but many of them 
probably are not interested in buying a book to do that, now.

Although you can gather the info if you know a fair amount of C and you 
are a decent developer (in any language, I mean), youngsters or newbies 
that don't know C and/or can't browse the Internet for tech docs are out 
of the game.

Usually lua-l friendliness compensated for that, but you must be willing 
to jump through hoops a good deal anyway.
It's no surprise that lately the only new users I see on lua-l seems to 
be expert programmers. I don't see many new users that describe 
themselves as newbie developers or students (I hope I'm wrong).

And mind you, I hear ever more people wanting to embed Python nowadays!

The very few cases in which I was in the position of suggesting Lua, I 
was told something like "I/we/my colleague already use Python for 
something else, so it will be easier to use after we embed it."
That makes me fear that Lua is losing terrain even on one of its BEST 
selling point!

</rant>

Anyway, sorry for the rant! :-)

Cheers!


  -spc



-- Lorenzo Donati