RE: __gc support for tables
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Wed, 3 Sep 2014 18:42:24 +0000
Just to add fuel to this...
When I first met LuaJIT, I went through the same exercise of wanting finalizers
on tables.
then I examined why I really wanted that, and thought about the resources I was
handling, as Mike points out.
Then I slipped into a habbit of just coding up the specific CData structures I
needed to manage with their attendant constructors and finalizers.
This works out waaaay better, and gives you independence from the Lua table, in
terms of lifetime.
If you want to see a ton of examples of doing this with real world APIs
(Windows), you might paruse the sources here: http://github.com/wiladams/tinn/
Or, for Linux, here: http://github.com/justincormack/ljsyscall
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
----------------------------------------
> Date: Wed, 3 Sep 2014 19:53:03 +0200
> From: mike-1409@xxxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Subject: Re: __gc support for tables
>
> Roman Tsisyk wrote:
>> Do you have any plans to support `__gc' metamethod for tables in
>> LuaJIT 2.0.x / 2.1.x?
>
> Scheduled for the new GC, which is not part of 2.x.
>
> In general, finalizers are for cleanup of resources that are NOT
> memory resources. A plain table only uses memory resources, but it
> may reference objects that do (userdata, cdata). Finalizers should
> be attached to these objects, not to the containing table.
>
> An assumed need to attach a finalizer to a table is often misguided
> and the overall data structure design should be reviewed. There are
> very few valid reasons to do this, which is why there has been no
> pressing need to implement finalizers for plain Lua tables. Like
> all finalizers, it has it's hidden costs.
>
> --Mike
>
Other related posts:
