[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Which thread does the garbage collector run in?
- From: Rici Lake <lua@...>
- Date: Fri, 8 Dec 2006 15:29:10 -0500
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
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().