lua-users home
lua-l archive

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

On 12 Aug 2005, at 15:42, David Given wrote:
Hmm. It has possiblities. Thinking off the top of my head, some questions that
come to mind are: What about function calls?

Because the finalised object is stored at the lua_State level, it should survive function calls. Only thing to prevent is garbage collection from happening in the middle of garbage collection, assuming this hasn't already been prevented.

Would doing this still allow you
to pass the finalised object in as a parameter?

Hmm - actually, I'm wrong - wrong op codes.

I believe load and move only apply to locals, intermediates and function calling conventions? All of these should be ok - these can only effect their own scope and below. What must be prevented are up value accesses (their own opcode, iirc?) and global accesses, done through preventing table sets, which also prevents a local table reference from leaking a reference.

What about constructing a
table containing the object and then saving the table?

The above should prevent the finalised object from being made a table member. :)

but it *does* mean that objects may have their finalisers
called multiple times.

Surely the postamble to the code that calls the finaliser could disarm the finaliser, preventing multiple fires?

The garbage collected also has to be more complex,
because when you resurrect an object to put into the table, you need to make
sure that none of its members have been collected.

Surely it doesn't get resurrected? The GC is doing the collect, so once it reaches this object, it can put it into the table. Prior to that instant it wasn't aware the object was redundant. Therefore, all of it's children will still consider it a valid reference, and so can't have been collected prior to this point. Since the GC doesn't collect it, but puts it in the table, it remains a valid reference, so the children don't get collected after that point.

Really should sort my sig out