Ok, in that case, do you have any suggestions for how to terminate daemon threads cleanly? I had no idea this was an issue. The only thing I can think of is to keep a shared registry of all TaskPool objects and send them stop signals on module destruction. However, having to keep such a registry would be kind of annoying. One thing that I definitely don't want is to punt the problem to the user of std,parallelism, because it's the kind of low-level thing that the module is supposed to abstract away.
On Wed, Sep 14, 2011 at 10:31 AM, Sean Kelly <[email protected]> wrote: > A regular collection is run. > > Sent from my iPhone > > On Sep 14, 2011, at 4:36 AM, David Simcha <[email protected]> wrote: > > > 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 > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
