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).
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.
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?),
