[D-runtime] A mechanism to kill threads

[Sean Kelly]

Right.  This is why I don't want the functionality in core.thread.  There are potentially legitimate reasons to kill a thread, but exposing it in the library effectively sanctions it as acceptable behavior, when this absolutely isn't the case.  Unless there were some reason why it absolutely couldn't be done without support in core.thread, I don't think inherently unsafe operations should be exposed to the user.

On May 16, 2012, at 2:36 PM, Alex Rønne Petersen wrote:

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