I don't know much about these kinds of internals.  I just assumed it was feasible because things like SIG_TERM get sent somehow when you kill a process on Linux.

On Wed, Sep 14, 2011 at 2:53 PM, Sean Kelly <sean at invisibleduck.org> wrote:

> On Sep 14, 2011, at 10:03 AM, David Simcha wrote:
>
> > How about this:  Could we send all daemon threads hardware exceptions
> after joinAll()?  In the vast majority of cases, locks will be scoped, either through synchronized blocks or simple scope(exit) mutex.unlock() type statements.  If they're not then they should be.  (If any still aren't in std.parallelism then I'll fix this.  I originally made a few non-scoped around code that couldn't throw, but this was silly and I think I changed all of them.)  This way daemon threads terminate immediately, locks get released if the code's well-written,
> > and if you **really** need to do some cleanup, you can catch the
> exception.
>
> How would we do this?  Signals don't cause an exception to be thrown
> (because it's technically illegal to throw from a signal handler).  Is there
> some other way we could sent a hardware exception to a thread that would
> cause it to terminate cleanly?
> _______________________________________________
> 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/4f837f86/attachment.html>

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
>

Looks like it should work.

On Sep 14, 2011, at 8:10 PM, David Simcha wrote:

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

On 9/16/2011 1:41 AM, Sean Kelly wrote:
> Looks like it should work.
>

Please merge then.  (I think you have commit privileges for Phobos, but I'm not sure.)  I'm really curious whether this will solve the annoying segfaults on FreeBSD64.

As all threads are suspended for the final collection run,
one could possibly set a shared flag on runtime termination
and let the threads exit with an exception after resuming.
But this would still be after all module dtors ran.
It would be also pretty hard to find bugs triggered by this exception
(e.g. non-scoped mutexes).


On Wed, 14 Sep 2011 21:07:21 +0200, David Simcha <dsimcha at gmail.com> wrote:

> I don't know much about these kinds of internals.  I just assumed it was feasible because things like SIG_TERM get sent somehow when you kill a process on Linux.
>
> On Wed, Sep 14, 2011 at 2:53 PM, Sean Kelly <sean at invisibleduck.org> wrote:
>
>> On Sep 14, 2011, at 10:03 AM, David Simcha wrote:
>>
>> > How about this:  Could we send all daemon threads hardware exceptions
>> after joinAll()?  In the vast majority of cases, locks will be scoped,
>> either through synchronized blocks or simple scope(exit) mutex.unlock()
>> type
>> statements.  If they're not then they should be.  (If any still aren't
>> in
>> std.parallelism then I'll fix this.  I originally made a few non-scoped
>> around code that couldn't throw, but this was silly and I think I
>> changed
>> all of them.)  This way daemon threads terminate immediately, locks get
>> released if the code's well-written,
>> > and if you **really** need to do some cleanup, you can catch the
>> exception.
>>
>> How would we do this?  Signals don't cause an exception to be thrown
>> (because it's technically illegal to throw from a signal handler).  Is
>> there
>> some other way we could sent a hardware exception to a thread that would
>> cause it to terminate cleanly?
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos