[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [BUG] table will be garbage collected multiple times
- From: Andrew Gierth <andrew@...>
- Date: Mon, 19 Nov 2018 01:24:23 +0000
>>>>> "Philippe" == Philippe Verdy <verdy_p@wanadoo.fr> writes:
Philippe> It's not very well documented, but when a finalizer gets
Philippe> called on an object, just before calling it, the GC first
Philippe> clears the associated metatable if the object being finalized
Philippe> is a table: in the finalizer for an object whose type is
Philippe> 'table' or 'userdata', if you use getmetatable(self), it's
Philippe> not documented clearly if either you'll get nil, or you'll
Philippe> get the same metatable whose "__gc" entry is now nill,
Philippe> something that should be better, allowing you to store the
Philippe> "cnt" variable inside the metatable itself along with the
Philippe> "__gc" variable, instead of the object being finalized).
I really don't know where you're getting this stuff, but it's all wrong.
The metatable of an object isn't changed in any way by garbage
collection, unless the __gc method chooses to do that itself (which is
sometimes a good idea, especially for userdatas where allowing method
calls on a post-finalization object(*) may be unwise). Inside the __gc
function for an object (whether table or userdata), getmetatable(self)
has the same value it had just before the object was collected, and
getmetatable(self).__gc is the __gc method being executed. Nor is the
metatable changed after the __gc method completes.
(*) - references to post-finalization objects can be easily obtained via
the keys of ephemeron tables
--
Andrew.