[phobos] parallelism segfaults

[David Simcha]

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 <sean at invisibleduck.org> wrote:

> A regular collection is run.
>
> Sent from my iPhone
>
> On Sep 14, 2011, at 4:36 AM, David Simcha <dsimcha at gmail.com> 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
> >> phobos at puremagic.com
> >> 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
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110914/b0da70cb/attachment.html>