Re: Hooking into garbage collection

[Rena <hyperhacker@...>]

On Sun, Dec 29, 2013 at 11:28 PM, Philipp Janda <siffiejoe@gmx.net> wrote:

Am 30.12.2013 03:38 schröbte Rena:

3) I wanted the parent thread to be able to use a "fire-and-forget" design:
create a thread and let it go off to work on something without having to
keep track of it.

That's what `pthread_detach` is for, but I guess you want to wait for all running threads before shutting down the main thread, right?

That's correct. Otherwise, unless I'm terribly confused, when the main thread exits, child threads can be prematurely killed (especially if they haven't yet noticed the signal to run).
 

So instead, we let the child thread continue to run after __gc and shut
down once it's finished.

Here's the problem: If the Thread struct in the child list doesn't get
deleted when __gc fires, then when *does* it get deleted? I'm envisioning a
scenario such as a server, where the parent thread might be running for a
very long time, creating many thousands of threads which run some brief
task (such as serving a request) and shut down.

If I have the child thread delete itself at shutdown, it raises concurrency
issues. If the child thread happens to finish execution and shut down just
as its __gc fires, then the __gc will try to set the "collected" flag on a
deleted thread -> segfault. I can't have __gc use a mutex to wait for the
thread to shut down either, since it might not shut down for a long time
yet, and I don't want the parent thread to block waiting for it. For
example in a server this means a long-running request could effectively
block all other requests until it finished.

When the parent thread shuts down, it will loop through its list of
children and pthread_join() all of them waiting for them to shut down. At
this point it'd be safe to delete them. Trouble is, if the parent thread
runs for a very long time and creates thousands of threads, then this
basically a memory leak - all those threads which have shut down ages ago
will still have a Thread object in the child list until the server is shut
down.

I'd use the membership in the parent's list as an indicator whether a thread should detach itself before exiting, and a reference count for determining if a child thread can free its Thread structure itself or has to let a `__gc` metamethod handle that. You will still need to protect the parent's list and the reference count with mutexes, but only for the time it needs to read/modify them.


Philipp

 

I'm not sure quite what you mean by this (by detach, you mean the thread should pthread_detatch() itself before exiting, and the parent not wait for it to terminate? what's the benefit of this?), but a reference count sounds like it might help. (I guess the "collected" flag is a bit like a reference count already.)

--
Sent from my Game Boy.