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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
