Re: state of the Lua nation on resource cleanup

[Cosmin Apreutesei <cosmin.apreutesei@...>]

Roberto, David, thanks for replying me.

>> In such language, there should be no difference (from the RAII pov)
>> between acquiring memory for a string and opening a file.
>
> Unless we're dealing with very large memory acquisitions that could
> fail, we often don't care about deterministic finalization for memory.
>  Not so for many other resources (e.g. things we might have only one
> of).

I wasn't very clear -- sorry -- what I meant was that I shouldn't care
about freeing external resource in the same way I don't care about
freeing a string or a table. They are all resources. Sure, strings and
tables are internally managed by the gc and so their release can be
delayed, while external resouces are not, but as a user, what do I
care? You shouldn't bring this on me. I'd rather have them all hooked
to the semantics of the gc and not surface out, in the same way that
the emergency gc doesn't surface out in userland.

>
>>> What if it has any other references to it? For instance:
>>>
>>> with f = file.open('somefile') do some_global = f end ... should f be
>>> closed by now? what would some_global hold now?
>
> As Roberto said.  Normally, that is a program error, like holding a
> pointer to a stack object that goes out of scope in C.  Don't do that.
>

But that breaks garbage-collecting semantics, which assures me never
to have invalid pointers no matter what... IMHO this brings me back
down to the C-level of responsibility (watching the stack).

That being said, I'd dare making a proposal that I've been giving some
thought, maybe I can hear your opinions about it (well, aside from the
trouble it would mean to implement it): how about an __immediate_gc
metamethod that would ensure finalization of a table or userdata when
the last reference goes out of scope.