[D-runtime] A mechanism to kill threads

[Alex Rønne Petersen]

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.

>
> 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)?

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.

>
> 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().

I should make it clear that I don't consider druntime "expert only". I
just consider it a place where you should *seriously RTFM* before you
use anything it exposes.

I agree that exposing a suspend primitive for individual threads is a
very bad idea; all sorts of Bad Things (TM) could happen if the user
starts interfering with individual suspend counts. Keep in mind that
what I'm asking for will: 1) acquire the global thread lock on every
call 2) kill the thread completely and remove it from the global
thread list. This makes it much less error-prone than a simple
suspend().

> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Regards,
Alex