[phobos] parallelism segfaults
David Simcha
dsimcha at gmail.com
Wed Sep 14 20:10:26 PDT 2011
Ok, I think I found a good way to fix this, though I'm not 100% sure
it's fixed because it's hard to prove that such sporadic problems are
really fixed. Thanks to everyone for their helpful hints.
https://github.com/D-Programming-Language/phobos/pull/256
On 9/14/2011 2:51 PM, Sean Kelly wrote:
> On Sep 14, 2011, at 7:37 AM, David Simcha wrote:
>
>> 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.
> First, I should mention that the thread ownership rules implemented in std.concurrency will pass an OwnerTerminated message to spawned threads when module dtors are run. So if you're using message passing the daemon threads should exit cleanly with an OwnerTerminated exception provided they call receive in a timely fashion.
>
> Otherwise, cleanup is just like when using threads in C/C++, and there are a variety of approaches. The general idea though is to either send a message to each thread or set a global flag and then block while waiting for the daemon threads to terminate. I'll usually have a timeout on this, so if a daemon thread doesn't terminate in a timely manner I'll just let the app exit, thereby forcibly terminating the thread (as you're seeing now). The timeout is just a failsafe so if a thread is hung for some reason the app doesn't wait indefinitely for it to terminate.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
More information about the phobos
mailing list