zlacker

>>djha-s+(OP)
Externally canceling a task at a location other than a known stopping point is used as an example here, but in most environments doing this is a known-bad design decision, since the terminated thread-or-task might have been holding a mutex, and now that mutex is stuck closed forever. .NET has been closing the door on this primitive for years (https://learn.microsoft.com/en-us/dotnet/core/compatibility/...)

>>keving+F7
It makes me wonder if there are any language constructs that can make this a reasonable feature. One idea I've been tossing around is having the ability to roll back any changes to mutex-guarded data if an exception drops a mutex guard. It should be possible with the right language constructs and bookkeeping.

Perhaps there are other mechanisms out there too.

I feel like the ability to destroy another thread isnt inherently bad, just... bad with today's languages. Just a feeling though.

>>verdag+k9
The Go folks will repeat the aphorism, "Do not communicate by sharing memory; instead, share memory by communicating."[1]. The author directly violates the intention of the designers of Go by talking about shared file handles and other data structures, i.e. memory.

The word "channel" doesn't appear a single time in the article, even though goroutines without channels to communicate with each other should never be sharing data. Channels are the synchronization primitive in Go.

1. https://go.dev/blog/codelab-share

>>crater+O9
Channels would help but the author is saying they're naively shared through a closure and that's a problem, no?