Post #4276593

2026-07-31 11:14 UTC

@icing@chaos.social @david_chisnall@infosec.exchange I think I adopted a rule to not try doing it (in C or any other proglang) because of all the prickly failure modes. in Golang we have the luxury of either using channels to convey that desire to the target thread, or, cancelling a "context" in Golangspeak. in early Java days I remember they also first designed it with an API for externally cancelling a java.lang.Thread and then abandoned it there too as too dangerous. I would not be shocked to learn if Java 1.0's impl of thread cancelling was itself a wrapper around pthread_cancel too.

Replies (1)

@david_chisnall@infosec.exchange 2026-07-31 11:23

@synlogic4242@social.vivaldi.net @icing@chaos.social POSIX threads were standardised in 1997. A lot of operating systems didn't even have threads back then, or had cooperative ones only. So I don't blame the standard for getting things wrong. Java came out two years earlier, so gets a similar pass. I think .NET has the nicest model I've seen for this (though not until .NET Framework 4.0). They have cancellation tokens, which have two handles, one that lets you signal cancellation and another that lets you check for cancellation. This lets you send a fan-out or point-to-point cancellation message. APIs plumb cancellation tokens through, so anything that might need to return early takes a reference to the cancellation token (the transmit handle is referred to as a cancellation token source). At places where it might make sense to cancel, you check the cancellation token. It's cheap (acquire-consistency atomic load), and the cancelled thread gets to decide where to exit.

Open ##4276592