[D-runtime] A mechanism to kill threads

Sean Kelly sean at invisibleduck.org
Wed May 16 14:44:12 PDT 2012


On May 16, 2012, at 2:32 PM, Jonathan M Davis 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.

If the killed thread even has a chance of allocating memory ir could be killed while inside the GC and lock all threads out of the GC forever.


More information about the D-runtime mailing list