Re: Garbage collection durint pcall.

[Francisco Olarte <folarte@...>]

Gé:

On Mon, Jun 3, 2019 at 7:40 PM Gé Weijers <ge@weijers.org> wrote:
> On Mon, Jun 3, 2019 at 9:37 AM Francisco Olarte <folarte@peoplecall.com> wrote:
>> I'll just assume finalizers are tainted and avoid them [...]
> Finalizers can run at any time, and could potentially run in the middle of the execution of any statement, this is true even if Lua had a guarantee that the lifetime of the object extends to the end of the block/scope containing the last reference.

I know they can run at any time. I just assumed they didn't run where
accessible and they were something like thread safe ( I know lua does
not multithread, but I assume that if I do a=a+1 in the main code and
a=a+1 in some finalizer I assumed VM will not interleave byte code
execution in such a way that I miss one of the increments. This seemed
pretty safe  ).

> They're not "tainted", but you have to guarantee that the finalizer can be run at any possible point in your main program without breaking any of the assumptions (invariants) you make in your code.

By tatinted I just meant they do not run too early, as I use them for
locking stuff. I think current versions, even 5.4, do it.

> If the finalizer just closes a file that's no longer needed that is obvious, because it does not reference anything but the object that's 'invisible' to the rest of your program, but if the finalizer changes global state that'll be very difficult if not impossible, because that finalizer may run in the middle of any statement.

My problem is I do not want some kind of optimizer to decide when I no
longer need an object. I'll tell that in my code. And the problem of
running the finalizer in any point, as long as it does not do weird
things like described above is, maybe not easy but solved, I've
written enough multithreaded code to do it. One of the things I use to
do this is assume the finalizer cannot run before some point ( which I
indicate ) because I'm touching related global data. It can still be
done if PUC changes the definition to something like the discussed
definition, is a little more complex.

OTOH, everybody tells me things like I'm counting on finalizers been
run at some point. I'm not, if I want code run, I call it. I count on
finalizers NOT being run. Anyway, that's no longer a problem.
>
> If you're using a finalizer in a userdata object you have a little bit more freedom because you can write your object's methods in such a way that state updates look atomic from the point of view of the Lua interpreter, but you still have to be very careful.

I have programs with runtimes measured in years, some times
interrupted only due to hardware problems. I'm normally too careful.
And for this reason is why I do not want a language with too many
freedom in potential optimizers, because I do complex things and I
need to be careful, and I do not want early finalizations. Current
version is Ok, future ones I do not care, I'll read the specs when
they come, I've already set up some archival copies of versions which
the behaviour I like.  When I say tainted what I meant is "I cannot
easily determine the earliest point of running ( or it is too early,
such as "just after creation" )". As I am normally careful I count on
that, and early finalization cab be hazardous, late one just makes my
program slow. But, being careful, I just assume "taintedness", I'll
assume finalizers can run very earlier from now on. This would lead to
me not being able to use them for certain things, but it has a simple
solution, classical resource management, passing around everything,
checking everything, It's just a little bit tedious. Or I'll just do
everything on the C++ side, where the lifetimes are better defined (
and that will improve myc ode, I not only will have my minimum
lifetime, but also the maximum one ).

Francisco Olarte.