[D-runtime] A mechanism to kill threads

[Brad Roberts]

If you have code like this, how can you make the claims you have about 
knowing it to be safe to kill the threads in question.  I'm with Sean on 
this, killing threads is a really bad idea and having an api is going to 
result in pain.

The only safe way to do it is akin to what you describe above.  Rely on 
some communication path into the other thread to ask it to kill itself 
when it's actually safe, not just believed to be.

It's a lot like so called lockless programming.  It's _really_ hard to get 
right.  Even the experts get it wrong fairly frequently.  When you can 
avoid it, avoid it.  There are safe ways of asking a thread to exit 
itself, so that should be the much preferred method.

You're obviously a bright guy and know all this, so what's pushing you so 
hard to go in an obviously unsafe direction rather than the obviously safe 
one?

On Thu, 17 May 2012, Alex R?nne Petersen wrote:

> Trust me, I've evaluated every option I could think of. Even
> cooperative suspension/killing won't cut it because a while (true);
> inside a VM thread could prevent the cooperative kill from actually
> happening at all.
> 
> E.g.:
> 
> void myThread()
> {
>     while (run)
>     {
>         runUserCode(); // if this never returns, the thread will never stop
>     }
> }
> 
> Regards,
> Alex
> 
> On Thu, May 17, 2012 at 12:55 AM, Sean Kelly <sean at invisibleduck.org> wrote:
> > On May 16, 2012, at 3:42 PM, Alex R?nne Petersen wrote:
> >
> >> The trouble is that they have to have version blocks for every
> >> platform and every threading library supported. The fact that
> >> core.thread supports pthreads should not even be known to code that
> >> extends the Thread class; it's an implementation detail (other
> >> threading libraries exist, especially on Linux). I believe there is
> >> currently active work to make GDC support other C libraries, and I
> >> imagine that involves other threading libraries on rather exotic
> >> platforms too.
> >>
> >> The way I've always seen core.thread is as a fundamental building
> >> block for threading; it should hide the native threading interface
> >> completely so people shouldn't have to mess with those at all.
> >
> > I tend to agree, though for some of the really risky stuff I think it may be fair to expect the user to be familiar with the platform specifics of what he's trying to do.  Kill threads, for example, works differently on Posix vs. Win32 and is (surprise surprise) actually a bit safer.  Regarding killing threads in general though, I wonder if there isn't perhaps a safer application-specific approach that you could use.  Could these threads periodically check some global "cancel" state and exit if set?  Is it truly necessary to have an external thread violently kill them?
> > _______________________________________________
> > 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
>