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.<br>
<br><div class="gmail_quote">On Wed, Sep 14, 2011 at 10:31 AM, Sean Kelly <span dir="ltr"><<a href="mailto:sean@invisibleduck.org">sean@invisibleduck.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A regular collection is run.<br>
<br>
Sent from my iPhone<br>
<div><div></div><div class="h5"><br>
On Sep 14, 2011, at 4:36 AM, David Simcha <<a href="mailto:dsimcha@gmail.com">dsimcha@gmail.com</a>> wrote:<br>
<br>
> On 9/14/2011 1:04 AM, Sean Kelly wrote:<br>
>> On Sep 13, 2011, at 11:59 AM, Martin Nowak wrote:<br>
>><br>
>>> I've had a look the core dumps from the sometimes failing std.parallelism test.<br>
>>> The issue is one of having daemon threads running while the GC is unmapping memory.<br>
>>> Usually this goes unnoticed because the parallelism threads wait in a work queue condition.<br>
>>> Sometimes a daemon thread is awakening from it's GC suspend handler after memory was already<br>
>>> freed. This issue is already mentioned in a comment at gc_term.<br>
>>><br>
>>><br>
>>> Thread  obj = Thread.getThis();<br>
>>><br>
>>> ...<br>
>>> suspend<br>
>>> ...<br>
>>><br>
>>> if( obj&&  !obj.m_lock ) //<- segfault<br>
>>><br>
>>><br>
>>> I think we should bluntly kill daemon threads after thread_joinAll.<br>
>> 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.<br>

>><br>
>> 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.<br>

>> _______________________________________________<br>
>> phobos mailing list<br>
>> <a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
>> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
>><br>
><br>
> Is the finalizer guaranteed to be called on all GC-allocated class instances before program termination, or is a regular collection cycle just run?<br>
> _______________________________________________<br>
> phobos mailing list<br>
> <a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>