[D-runtime] A mechanism to kill threads

[Sean Kelly]

On May 16, 2012, at 3:57 PM, Alex Rønne Petersen wrote:

> On Thu, May 17, 2012 at 12:28 AM, Sean Kelly <sean at invisibleduck.org> wrote:
>> On May 16, 2012, at 2:51 PM, Alex Rønne Petersen wrote:
>> 
>>> It's the user's responsibility, just as with any of the other 'unsafe'
>>> functions. Also, it's the runtime, not the standard library. I think
>>> there is a significant difference between those two terms. You
>>> shouldn't touch the runtime in general unless you're prepared to go
>>> low-level.
>> 
>> 
>> I think that there are three important aspects of library design.  The first is to make it useful by exposing any functionality that is commonly needed by users of the library, or in some cases that is not commonly needed but which can't be done without library support.  The second is that this should be done with the understanding that the interface of a library provides a framework for how the library is to be used.  This is the really tricky part, because a library could expose the same functionality in two different ways and the applications built upon each would be fundamentally different.  The third is that the library should be no more complex than absolutely necessary.  Doing so tends to expose too many assumptions about how the library will be used, and tends to confuse things without really adding much of use.
> 
> The problem is that druntime's core.thread is supposed to hide the
> native threading mechanism being used. With the example in your other
> email, the abstraction is completely broken, and portability becomes a
> *giant* pain (especially because compilers don't set any flags
> indicating what threading library the runtime is built for). So, I do
> believe kill() would be an important primitive to have, as unsafe as
> it is.

Fair enough.  I'm still resistant to Thread.kill() however, both because of how unsafe it is and because this is actually the first time anyone has ever requested it.


>> What I've found is that when people thing of something useful for their program, if it's something regarding a library they tend to want to build that functionality into the library even if it doesn't need to be there.  The problem is that they may be the only person in the world that needs that functionality, and adding it to the library may increase maintenance cost to no one's actual benefit but that one user.  There have been a number of requests like this for Druntime, and some of the few that were accepted have just been deleted after having been deprecated for years, without a single complaint.  Assuming that people are actually using Druntime, I'll admit that I prefer to see it shrinking rather than growing.  It means that it's being distilled down to only containing the functionality that people actually care about.
> 
> What were some of those (out of curiosity)?

Runtime.isHalting, for one.  There were others I didn't implement for one reason or another, like the ability to join a thread with a timeout.


> I agree that keeping druntime small is a good idea - but IMO that
> shouldn't mean that we can't have the abstractions that actually make
> druntime useful. Obviously, I'm biased here, since this is a feature
> I, specifically, want. But I'm not convinced that it would never be
> used by anyone else. D is a systems language intended to be a
> competitor to C and C++. A virtual machine is just one example of a
> system that would need the functionality to destructively kill
> threads, regardless of whether all hell breaks loose as a result.

Suspending threads is actually similar, since debuggers do have a valid reason to suspend threads.  I suppose I'm just leery of exposing any functionality that could cause a deadlock.