Re: worst case time using hash-tables in Lua

[Francisco Olarte <folarte@...>]

Andrea:

On Fri, May 15, 2020 at 7:07 PM Andrea <andrea.l.vitali@gmail.com> wrote:
>> always considered a local variable could not be collected until the
>> scope containing it ended, from manual reading, RI told me more or
>> less not to count on it ( IIRC, implementation does not collect, but I
>> saw that l8r, I didn't rely on source, I relied on manual reading ), I
>> noted it and acted accordingly.
>  This is interesting. Can you be more specific? How can a local variable be collected if it is still in the scope?

Well, imagine you have.
>>>>
do
   local x = create_collectable_thing()
   y = 2
end
<<<<
My reading of the manual was x could not be collected until we reach
end. I was discussing with PV thighs like that, you'll find below some
text from him about optimizing tracing compilers and the like. The RI
stepped in and convinced me that it could be collected, as it is not
used. That is, the code could run as something like:

x = c_c_t()
x:__gc(), if defined.
y=2

The problem I have is I'm used to well defined behaviours. Like RAII
in C++, if you do something similar:
{
   some_class x();
   y = 2;
}
x is not destroyed until block end. Memory and low level stuff can be
done by an optimizing compiler, but as all optimizations they must be
transparent.

I'm used to scopes controlling resources, as my resources tend to be a
little complex I want thight control on them. If I switch to Lua 5.4 I
may use the new toclose stuff for tighter control. But the point is
when I do things like above I expect x to be created before Y is set
to 2 and to be collected at block exit. My problem with early
collection is lua has __gc methods, is something like this might
happen ( synthetic example, of course)
>>>>
-- This code can be hidden deep into another module....
y=1
local function create_collectable_thing()
  if y==2 then launch_nukes() end
  return setmetatable({}, { __gc = function() if y==1 then
launch_nukes() end end })
end
--- The previous code.
do
   local x = create_collectable_thing()
   y = 2
end
<<<

That's because not all my resources are just memory to be freed.

Real stuff in my code is much more complex, and has billing and
locking interactions. I do not mind a real smart optimizer freing the
memory early, but otherwise doing the same as the  unoptimized code,
i.e., it does not call launch_nukes(). But PV gave me the impression
he thought calling it was correct behaviour, and RI, whom I consider
one of the supreme authorities in Lua behaviour, confirmed it ( to me,
I may have misinterpreted it, but I doubt it ).

This led me to think Lua might evolve into one of those languages
whose properties are not well defined on a reference, so I began to
not trust the manual completely. And I stopped doing stuff which needs
lifetime guarantees in lua and moving it to other runtimes.

Enough for today, let this end here.

Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org