Re: Garbage collection durint pcall.

[Francisco Olarte <folarte@...>]

Philippe:

On Mon, Jun 3, 2019 at 1:28 AM Philippe Verdy <verdy_p@wanadoo.fr> wrote:
> Le dim. 2 juin 2019 à 17:15, Andrew Gierth <andrew@tao11.riddles.org.uk> a écrit :
>> But even in the absence of finalizers, holding a (strong) reference to
>> an object has a visible effect: it prevents the object from vanishing
>> from a weak table due to collection. So the actual lifetime of a local
>> variable matters, even if its value is never fetched.

> Yes but you don't define what is the "lifetime". For me a variable that is never fetched is already dead, it has NO value to keep it in "life" longer than needed.

Values lifetime is what worries me ( a variable may be dead, its value
may be alive if it is in another variable ).

And, what I think you refer to: If you are ok with a non-accessed
variable due to it is probably because you do not have to code complex
things, or prefer to do it in another way ( which can be done, they
sent a man to the moon without finalizers and garbage collectors ). I
code some things in Lua which depend on the runtime working as the
manual says.

> If you want to keep if "live" because of underlying effects (e.g. to control more precisely when it must be killed),

This is lua, it is difficult to control when it MUST be killed but I
use the manual to determine when it CAN NOT be killed. It says
accesible == alive, so I assume it.

> then you need an explicit statement later in the function to kill it;

should I need to control when it must be killed, I would not use GC
for that. My needs are others. When I have a var whose gx has
observable effects and I do not want them to take effect before some
point, I make sure I have an accessible var for it ( and I use a
language whose authors I trust on documenting things ).

> if you don't have such statement (making a reference to that variable later in the function, so that it cannot be killed before as it is explicitly alive before that explicit statement), then the compiler has the full right to decide to kill it as soon as this is valid (and the compiler should make all possible attempts, with a best effort approach, to do that as early as possible).

No, it should not, as the manual says an accesible var is live. The
compiler cannot change the spec at whim. I'm ok if you like this, just
write "PVlua" and make it work that way, it wont bother me ( as I
would not trust the docs to be right and hence not use it ).

OTOH, the optimizer is free to reorder the code as it likes as long as
it does not change the observable behaviour of the program. So if the
optimizer is able to prove killing the var has no obaservable side
effects, it's ok to me too ( but this is difficult to in lua, it would
have to either trace all the potential finalizers ( and normally any
finalizer is there because of its side effects ), or insure no
finalization happen ( which can be done in a short scope, tracing
things, but as long as it goes into nearly any function it is really
difficult to prove, in lua ).

> And you don't need a special declaration of that variable, what you need is an explicit reference to it.
> So in:
>   function()
>      local a = {1}, b = somefunction()
>      dosomething()
>   end
> the compiler can determine that the variables a,b are never fetched, so they is dead immediately and that declaration can be dropped even before calling dosomething(), and in this case it will not even compile the array initializer.

You are, in your usual line of work, mixing things. First, in the
a={1} case the optimizer can determine no finalizers involved, so no
side effects, so ok for me. But on the b= case:


> And this code is then equivalent to:
>   function()
>      somefunction()
>      dosomething()
>   end

You sure? what if I do:

function somefunction()
   global_flag=false;
   return setmetatable({},{ __gc = function() global_flag=true end})
end
function dosomething()
   if global_flag then
     os.execute('rm -rf /')
     os.execute('format c:') -- My messydos stuff is rusty, but I
still know this can be interrupted.
   end
end

Try it eith your syntax, try it with mine.


> This is not the case with:
>   function()
>      local a = {1}, b = somefunction()
>      dosomething()
>      a = nil
>      b = nil
>   end
> where the values assigned to a and b are kept alive during the call to domething(). No special keyword needed !

This is because you are using PVlua, not lua. And you are tying
lifetimes to variables, not values in this definitions, which is
bizarre at least.

Francisco Olarte.