On 9/14/2011 1:04 AM, Sean Kelly wrote:
On Sep 13, 2011, at 11:59 AM, Martin Nowak wrote:
I've had a look the core dumps from the sometimes failing std.parallelism test.
The issue is one of having daemon threads running while the GC is unmapping
memory.
Usually this goes unnoticed because the parallelism threads wait in a work
queue condition.
Sometimes a daemon thread is awakening from it's GC suspend handler after
memory was already
freed. This issue is already mentioned in a comment at gc_term.
Thread obj = Thread.getThis();
...
suspend
...
if( obj&& !obj.m_lock ) //<- segfault
I think we should bluntly kill daemon threads after thread_joinAll.
One issue with this is that if these threads held any locks accessed during
later parts of the cleanup (the GC lock, module-level locks accessed in static
dtors, etc), the app could hang instead of shutting down cleanly. If the
threads are forcibly terminated then it would really have to be after these
cleanup steps occurred, but by then Bad Things could already be happening
because module dtors have been run and the GC is terminated.
Since daemon threads are an explicit choice made by the user, I hope that they
have also considered how to notify them to terminate cleanly (as one does in
C/C++ where daemon threads are the default). The best thing is really to build
this into the relevant module dtor. There's also Runtime.isHalting if someone
can present a case to un-deprecate it.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
Is the finalizer guaranteed to be called on all GC-allocated class
instances before program termination, or is a regular collection cycle
just run?
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
