Re: forcing userdata to be gc'd?

[Patrick Donnelly <batrick@...>]

On Fri, Mar 31, 2017 at 3:24 PM, William Ahern
<william@25thandclement.com> wrote:
> On Thu, Mar 30, 2017 at 09:34:03AM +0200, Francisco Olarte wrote:
>> John:
>>
>> On Wed, Mar 29, 2017 at 10:51 PM, John Dunn <John.Dunn@qsc.com> wrote:
>> > It seems like a way to tag something to always be garbage collected as soon as there are no longer any references might work.
>>
>> This idea is it needs two parts. One to detect the "as soon as there
>> are no longer any references" plus another to "tag something to..." (
>> and implement the special collections for this ). If you have the
>> first one, why bother with the second, just _gc it instead of tagging.
>>
>> Reference counting is something which must either be built deeply into
>> the language ( like perl or C-python ) or be implemented in a language
>> which gives you more control on your data ( like C++, where you can
>> mix manually managed, reference counting and garbage-collected data in
>> the same program ). I, particularly, would love to have a way to
>> choose ( as my objects typically split into two categories, things
>> like sockets, db handles, files, which do not participate in cycles (
>> or can easily be made not to ) and would like to have managed in a
>> release-fast way and memory-chunk-like data which I do not care when
>> it is freed. That's why I favour C++ ways, where I manage my heavy
>> resources with reference counting and use garbage collectors or memory
>> pools ( where you free the whole pool ) for things like graphs.
>
> Either Roberto or Luiz once proposed a construct that automatically invoked
> a __close metamethod on an object upon exiting a block. IIRC, it would be
> invoked even if scope exit occured because an error was thrown.
>
> I thought that was a cool idea. It's similar to the using, with, and defer
> statements of other languages.

Out of all the possible features of the next release, this is the one
I'm most looking forward to!

> I suppose all it would really require is a linked-list, stack-like data
> structure adjacent to the jmp_buf structure used for exception handling.
> Plus some new opcodes and changes to the code generator. Some of those
> changes might be tricky.

As mentioned in the thread bringing the feature up a year or so ago,
the mechanism would piggy back on the same code that closes upvalues
(as closing upvalues must also deal with errors and block scope
ending). It shouldn't require any new data structures I believe.

-- 
Patrick Donnelly