[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