Hi,

In my virtual machine, I need to be able to kill daemon threads on shutdown. The problem is that VM shutdown is *not* tightly coupled to druntime shutdown; multiple VM instances can run in a process at any given time, and can be started/stopped whenever. It doesn't appear like there is any functionality in core.thread to achieve this.

Is there any reason we don't have a Thread.kill() function?

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wednesday, May 16, 2012 19:04:48 Alex Rønne Petersen wrote:
> Hi,
> 
> In my virtual machine, I need to be able to kill daemon threads on shutdown. The problem is that VM shutdown is *not* tightly coupled to druntime shutdown; multiple VM instances can run in a process at any given time, and can be started/stopped whenever. It doesn't appear like there is any functionality in core.thread to achieve this.
> 
> Is there any reason we don't have a Thread.kill() function?

Because it's incredibly unsafe? You may have a valid use case for it, but it's _not_ something that you should normally be doing.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).

Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?

Regards,
Alex

On Wed, May 16, 2012 at 8:47 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Wednesday, May 16, 2012 19:04:48 Alex Rønne Petersen wrote:
>> Hi,
>>
>> In my virtual machine, I need to be able to kill daemon threads on shutdown. The problem is that VM shutdown is *not* tightly coupled to druntime shutdown; multiple VM instances can run in a process at any given time, and can be started/stopped whenever. It doesn't appear like there is any functionality in core.thread to achieve this.
>>
>> Is there any reason we don't have a Thread.kill() function?
>
> Because it's incredibly unsafe? You may have a valid use case for it, but it's _not_ something that you should normally be doing.
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wednesday, May 16, 2012 20:57:15 Alex Rønne Petersen wrote:
> Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).
> 
> Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?

Well, I wasn't saying that it's necessarily the case that we shouldn't add it. I was pointing out that it's a very unsafe thing to do and rarely needed such that it's not exactly surprising that it hasn't been added previously. If there's a real use case for it, it makes sense to add it given that it _is_ something that's platform dependent, and part of the whole point of Thread is to provide a platform-independent API for handling threads. It probably _should_ have a big fat warning on it though, given that not all developers seem to get how insanely bad it is to kill a thread (at least, that seems to be the case given some thread-related questions I've seen in the past).

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wed, 16 May 2012 20:57:15 +0200
Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).
> 
> Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?

yes, suspending makes the code that is executed during the suspension
"unsafe" (meaning that it can do only things that can be done in a
signal handler).
Killing makes all the rest of the program have such constraints...

Fawzi
> 
> Regards,
> Alex
> 
> On Wed, May 16, 2012 at 8:47 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Wednesday, May 16, 2012 19:04:48 Alex Rønne Petersen wrote:
> >> Hi,
> >>
> >> In my virtual machine, I need to be able to kill daemon threads on shutdown. The problem is that VM shutdown is *not* tightly coupled to druntime shutdown; multiple VM instances can run in a process at any given time, and can be started/stopped whenever. It doesn't appear like there is any functionality in core.thread to achieve this.
> >>
> >> Is there any reason we don't have a Thread.kill() function?
> >
> > Because it's incredibly unsafe? You may have a valid use case for it, but it's _not_ something that you should normally be doing.
> >
> > - Jonathan M Davis
> > _______________________________________________
> > D-runtime mailing list
> > D-runtime@puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/d-runtime
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

For the sake of argument, what are the most non-obvious reasons why killing threads is bad?  The ones I can think of are because the thread may be in the middle of doing something important and bad things will happen if it's interrupted and because the thread might hold resources that will never get freed if it's killed before it gets to free them.

I was thinking at one point that I wanted a kill() primitive when I was designing std.parallelism, but I don't remember why I wanted it and obviously I've managed to do without it.  Is it ok to kill threads if they're not doing useful work at the time and they're not holding onto any resources that will never get freed if you kill them?

On Wed, May 16, 2012 at 5:04 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Wednesday, May 16, 2012 20:57:15 Alex Rønne Petersen wrote:
> > Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).
> >
> > Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?
>
> Well, I wasn't saying that it's necessarily the case that we shouldn't add
> it.
> I was pointing out that it's a very unsafe thing to do and rarely needed
> such
> that it's not exactly surprising that it hasn't been added previously. If
> there's a real use case for it, it makes sense to add it given that it _is_
> something that's platform dependent, and part of the whole point of Thread
> is
> to provide a platform-independent API for handling threads. It probably
> _should_ have a big fat warning on it though, given that not all developers
> seem to get how insanely bad it is to kill a thread (at least, that seems
> to
> be the case given some thread-related questions I've seen in the past).
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>

Well, I'll see if I can conjure some sort of patch for this.

I do have a more technical concern, though: Would a Thread.kill() function have to acquire the global thread lock to avoid racing against a world stop? At least the way I see it, that's going to be necessary.

Regards,
Alex

On Wed, May 16, 2012 at 11:04 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Wednesday, May 16, 2012 20:57:15 Alex Rønne Petersen wrote:
>> Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).
>>
>> Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?
>
> Well, I wasn't saying that it's necessarily the case that we shouldn't add it. I was pointing out that it's a very unsafe thing to do and rarely needed such that it's not exactly surprising that it hasn't been added previously. If there's a real use case for it, it makes sense to add it given that it _is_ something that's platform dependent, and part of the whole point of Thread is to provide a platform-independent API for handling threads. It probably _should_ have a big fat warning on it though, given that not all developers seem to get how insanely bad it is to kill a thread (at least, that seems to be the case given some thread-related questions I've seen in the past).
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

The only reason I can think of is exactly what you mentioned, but this is a non-issue because you *really* *should* *not* kill non-daemon threads, and daemon threads should be designed to handle 'abnormal' termination gracefully.

That said, I think it's okay to kill a thread which is just waiting for work, sleeping, or whatever. As long as it isn't holding onto a lock (or similar), you should be safe. Holding onto a resource like a lock could easily lead to a deadlock because the lock is never released when you kill the thread.

I think the TL;DR of all this is that you should really only kill threads if either a) you know they can tolerate it (daemon threads) or b) you know specifically what the thread is doing and that it's safe to interrupt that work and never resume it (speaking of which, killing a thread isn't really any different from suspending it and just never resuming it).

Regards,
Alex

On Wed, May 16, 2012 at 11:19 PM, David Simcha <dsimcha@gmail.com> wrote:
> For the sake of argument, what are the most non-obvious reasons why killing threads is bad?  The ones I can think of are because the thread may be in the middle of doing something important and bad things will happen if it's interrupted and because the thread might hold resources that will never get freed if it's killed before it gets to free them.
>
> I was thinking at one point that I wanted a kill() primitive when I was designing std.parallelism, but I don't remember why I wanted it and obviously I've managed to do without it.  Is it ok to kill threads if they're not doing useful work at the time and they're not holding onto any resources that will never get freed if you kill them?
>
>
> On Wed, May 16, 2012 at 5:04 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>>
>> On Wednesday, May 16, 2012 20:57:15 Alex Rønne Petersen wrote:
>> > Of course it's unsafe, but no less than arbitrarily suspending a thread. Once you've suspended a thread, you may as well kill it. You've effectively halted it anyway. We have lots of unsafe primitives in core.thread already (and my critical regions and cooperative suspension patches add even more!).
>> >
>> > Is there anything speaking against adding this to core.thread with a big fat "THIS IS UNSAFE" warning?
>>
>> Well, I wasn't saying that it's necessarily the case that we shouldn't add
>> it.
>> I was pointing out that it's a very unsafe thing to do and rarely needed
>> such
>> that it's not exactly surprising that it hasn't been added previously. If
>> there's a real use case for it, it makes sense to add it given that it
>> _is_
>> something that's platform dependent, and part of the whole point of Thread
>> is
>> to provide a platform-independent API for handling threads. It probably
>> _should_ have a big fat warning on it though, given that not all
>> developers
>> seem to get how insanely bad it is to kill a thread (at least, that seems
>> to
>> be the case given some thread-related questions I've seen in the past).
>>
>> - Jonathan M Davis
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
>
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wednesday, May 16, 2012 17:19:02 David Simcha wrote:
> For the sake of argument, what are the most non-obvious reasons why killing threads is bad? The ones I can think of are because the thread may be in the middle of doing something important and bad things will happen if it's interrupted and because the thread might hold resources that will never get freed if it's killed before it gets to free them.
> 
> I was thinking at one point that I wanted a kill() primitive when I was designing std.parallelism, but I don't remember why I wanted it and obviously I've managed to do without it. Is it ok to kill threads if they're not doing useful work at the time and they're not holding onto any resources that will never get freed if you kill them?

It's the same reason that you don't want to continue executing after an assertion fails. Your program is by definition in an undefined state. In this case, it would be a single thread which was then in an undefined state. If it were sufficiently isolated (e.g. doesn't use shared _at all_), it _might_ mean that the rest of the program is okay, but there's no question that anything relating to that thread is then in an undefined state, and odds are that that means that the rest of the program is also in an undefined state, though the impact is likely to be much less if the thread was well isolated. If you were using shared much though, there's not really any question that your whole program is then in an undefined state, and who knows what could happen if you tried to continue. And even without using shared much, the threading stuff is still built on top of C primitives which _are_ shared (well, __gshared), so by definition, there's at least _some_ portion of the rest of your program which is in an undefined state.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

In my particular case, the threads I'm going to kill are executing isolated managed code, so going into an undefined state can't really happen, but you're certainly right that it's entirely possible in normal C and D code. In fact, even .NET has a zillion warnings about using Thread.Abort(): http://msdn.microsoft.com/en-us/library/ty8d3wta.aspx

Regards,
Alex

On Wed, May 16, 2012 at 11:32 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Wednesday, May 16, 2012 17:19:02 David Simcha wrote:
>> For the sake of argument, what are the most non-obvious reasons why killing threads is bad? The ones I can think of are because the thread may be in the middle of doing something important and bad things will happen if it's interrupted and because the thread might hold resources that will never get freed if it's killed before it gets to free them.
>>
>> I was thinking at one point that I wanted a kill() primitive when I was designing std.parallelism, but I don't remember why I wanted it and obviously I've managed to do without it. Is it ok to kill threads if they're not doing useful work at the time and they're not holding onto any resources that will never get freed if you kill them?
>
> It's the same reason that you don't want to continue executing after an assertion fails. Your program is by definition in an undefined state. In this case, it would be a single thread which was then in an undefined state. If it were sufficiently isolated (e.g. doesn't use shared _at all_), it _might_ mean that the rest of the program is okay, but there's no question that anything relating to that thread is then in an undefined state, and odds are that that means that the rest of the program is also in an undefined state, though the impact is likely to be much less if the thread was well isolated. If you were using shared much though, there's not really any question that your whole program is then in an undefined state, and who knows what could happen if you tried to continue. And even without using shared much, the threading stuff is still built on top of C primitives which _are_ shared (well, __gshared), so by definition, there's at least _some_ portion of the rest of your program which is in an undefined state.
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime