lua-users home
lua-l archive

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

2018-07-20 12:44 GMT+02:00 Hisham <>:
> You can have immediate release of resources by calling foo:close() by
> hand in every possible exit of your function, but that's not implicit.
> (And not being implicit is a problem: throw the first stone they who
> never forgot to close()/free()/release() a resource is some of their
> code paths — that's why languages have garbage collection for memory
> management, after all — but memory is not the only kind of resource
> managed in a program.)

Memory is also kind of the most unimportant resource to manage.
Important in the sense of "doing something useful", like network
communication, file I/O, calling external APIs for rendering
or generating printed reports.

Thats also why I really like reference counting and/or call stack
based resource management (like C++, Lisp or Scheme supports).

But most of the time I get by with a resource allocating wrapper function
that also catches exceptions, like:

    function with_printer_handle(constructor_args, doItFn)
        local handle = create_printer_obj(constructor_args)

        local s, err = pcall(function() doItfn(handle) end)
        if (s) then

I remember that the Parrot VM project a few years back was very convinced
to solve the problem of RAII, timely destruction and GC.
Unfortunately the whole Perl 6 and Parrot VM project(s) fell victim to
the second-system effect.

I would love a Lua with reference counting. I would even be willing to pay
the CPU overhead for that.

Reflecting on the GC concept: Shouldn't we as developers be worried
of introducing such a non-deterministic mechanism into our programs?
We already have to deal with enough non-determinism in our systems:
like kernel controlled preemptive threads and process scheduling
or hard disk and network latencies.
It's obviously a trade off, but I for myself decided that I would rather
like the reference counting trade off. Where I have to take care of
cycles using weak refs, and pay the CPU overhead.
It's not perfect, but I am in control and it solves managing arbitrary resources
in most cases well. And in the other cases, where I generate cycles
(happens quickly if
you use closures) I have a resource leak that is not obvious and hard
to track down.