[D-runtime] A mechanism to kill threads

[Sean Kelly]

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.

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.

Regarding Druntime's "expert only" status… Druntime still follows the core tenet of D which is that the design should encourage people to do things the "right way" by making that approach inherently easy.  For example, the GC needs to suspend and scan threads so it can collect unused memory.  This functionality is absolutely needed.  But an important observation is that the GC only ever needs to suspend and scan all threads in bulk--never just one at a time.  So rather than exposing a Thread.suspend() routine as in Java, Druntime only provides a way to suspend all threads at once.  This makes it far more likely that the functionality will only be used as was intended--by the GC--rather than by users as a means of implementing synchronization.  And if you don't think people use suspend() in this way you need look no farther than Doug Lea's containers library.  He's clearly an expert and so Gets it Right, and he's admittedly doing it by necessity since Java doesn't have semaphores or whatever, but I think it's a fair point all the same.  What should have happened was for semaphores to be added as a separate API so Doug didn't have to cowboy it with suspend().