[eggsnbacon1]

Java does not allow one thread to kill another due to its shared memory concurrency model. It actually used to, but this feature was removed because it caused so many deadlocks. The reason is that killing threads won't always release monitors and locks. Lack of the feature is intentional.

You can get a lot better nonblocking support with third party libraries. Like RxJS in javascript, RxJava is almost a requirement when doing non-blocking code.

You are right that true green threads would allow thread cancellation one day. Right now, Java can't because it relies on OS threads which aren't safe to cancel. Userspace threads don't have that problem

[mrkeen]

> Java does not allow one thread to kill another due to its shared memory concurrency model. The reason is that killing threads won't always release monitors and locks.

I can't follow the reasoning here. To refute it, you'd only need to show a language with shared memory and futures with cancel(), right? Aside from that, a second shortcoming isn't a good excuse for the first.

> You can get a lot better nonblocking support with third party libraries.

I don't doubt this. Another example is vavr.io, which gives much better Lists/Optionals/Streams than the standard Java 8 ones. And Joda-Time before that.

> RxJava is almost a requirement when doing non-blocking code.

Why can't CompletableFutures do what RxJava did?

> it relies on OS threads which aren't safe to cancel. Userspace threads don't have that problem

This bit was the most confusing to me. In my shitty understanding of the model, Java Threads are based on OS threads, which is why they're relatively heavy. CFs on the other hand are are lighter and managed by the Java runtime. Why is it then that I can cancel Threads, but I cannot cancel CFs. Your explanation would seem to justify the opposite.

[eggsnbacon1]

Maybe I muddled my words on this. Java supports "requesting" thread cancellation, but its not safe to forcibly kill OS threads in any language I know of. For the same reason you can't in Java, finalizers won't run. This includes C and C# among others that use OS threads. https://stackoverflow.com/questions/13285375/how-to-kill-a-r... https://stackoverflow.com/questions/1327102/how-to-kill-a-th...

Notably C lets you do it with the big warning that it can crash everything. C# made the same decision as Java and doesn't allow it.

Java and pretty much all OS thread-using languages DO allow you to end threads by nicely asking them to stop. This is not the same as forcing them to. In all cases, if a thread is stuck in an infinite loop or a blocking call, it probably won't cancel if you ask it to. It depends on whether the thread is written to handle cancellation properly.

This is also a limitation of some languages with fibers, including Erlang. You can't force a thread thats stuck in certain states to stop running in Erlang even though it uses fibers. Some languages with fibers do allow it though.

[mrkeen]

> Maybe I muddled my words on this.

Not at all. Thanks for your patience.

You've laid out really good arguments as to why Java Threads cannot be cancelled, and suggested that userspace threads -- which I (perhaps mistakenly) interpreted as CompletableFutures -- should be able to be cancelled.

But the thing is, I can cancel (request) Java Threads. And I cannot cancel CompletableFutures.

From my original comment:

> But CFs lack the functionality of Threads. A CF can't decide to sleep for a while, nor can it be cancelled.

[toast0]

What conditions do you need to get an Erlang process that you can't kill? Brutal kill, or load the executing module twice always worked for me (except for a couple deadlock bugs my company added to our locally patched BEAM)