[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Hooking into garbage collection
- From: Tim Hill <drtimhill@...>
- Date: Fri, 27 Dec 2013 19:08:33 -0800
On Dec 26, 2013, at 5:52 PM, Rena <hyperhacker@gmail.com> wrote:
> I have a module that allows Lua to create some objects. Each of those objects has its own OS thread doing some work. Even if the Lua state that created them discards the reference to them, I want those threads to run to completion. That's simple enough; just make the Lua objects only pointers to them, and don't delete them when the reference is collected.
>
> The problem is, they do need to be deleted eventually, and that might be long after the Lua state that created them has discarded and collected all references to them. I don't think it'd be terribly easy for them to clean themselves up, either - the thread that created them should be the one to delete them (or else the design becomes a lot more complicated).
>
> What seems like the best option is to have the parent Lua state periodically call a "cleanup" function, which will go through all objects which are ready to be disposed (thread has finished and Lua has collected the references) and delete them.
>
> From there, it seems like a no-brainer: Lua already periodically calls a function to clean up its own garbage. Is there some nice way to get a callback for each garbage collection cycle, so I can clean up these objects too?
>
> I feel like one method might be to take advantage of __gc: create some object in the registry (or even only on the stack) and then immediately discard all references to it, so that it gets collected on the next cycle. Then in that __gc callback, prune any objects ready to be discarded, and push (and immediately discard again) another reference to this placeholder object (or a new one), so that __gc fires again on the next cycle. But I'm not sure this will work (the manual mentions something about finalizers only running once), and it seems like an ugly hack.
>
> --
> Sent from my Game Boy.
I think this is one of those “solution is worse than the problem” things. The real issue here is why is it so hard for the OS thread to clean itself up? The correct pattern here is to use __gc to tell the object that Lua has finished with it, and it can then take appropriate actions. If you need Lua to know what the thread has finished work you will have to construct some sort of async event mechanism (a postbox, in effect), so that Lua can figure out when the object has “really” finished.
—Tim