 |
lua-l archive |
|
|
||
|
On 8-Dec-06, at 2:56 PM, Chris wrote:
An interesting fix would be to have a way to defer collection. If in the __gc metamethod you could return true/false as to whether or not the object is ready for collection that would work for my situation. With this I could delay collection until the main thread ran the collection. Seems like a simple change but after looking at lgc.c I'm not sure where to start. Of course that is still not an ideal fix but it would work for me. An ideal fix would have a separate collector for each thread. It would be OK if they all ran at once when any collection is triggered (or they could even run one after another for each thread to reduce mutex thrashing).
I'm not sure what problem you're trying to solve here. If the memory allocator which Lua is using (i.e. the system malloc() by default) requires that memory be free()'d from the thread which malloc()'d it then you're out of luck entirely, because Lua does not have the concept of a memory block belonging to a thread.
If there is something else which you need to do to release resources, then you would have to keep track of the thread which acquired the resource yourself; you could then maintain a list of resources to be released per thread and add to the appropriate list when your __gc metamethod triggers (unless it happens to be running in the correct thread). Of course, you'd need to figure out some mechanism to ensure that the threads did run the release list, possibly in lua_lock().