[D-runtime] A mechanism to kill threads

Sean Kelly sean at invisibleduck.org
Wed May 16 15:55:55 PDT 2012


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?


More information about the D-runtime mailing list