zlacker

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+(OP)
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+u
A file descriptor is nothing but a pointer. It's really just an int. Usually maintained by the OS.

Instead of sharing the file descriptor across a goroutine (bro, like WTF), let one go routine manage the file descriptor itself.

>>verdag+(OP)
It seems to me that what you are describing is usually called software transactional memory. It has its own set of problems (bad performance with high granularity and livelocks, although you can probably avoid livelocks if you only care about using it for abnormal terminations) but it doesn't fully resolve the problem here. Yes, not leaving memory in an invalid state goes a long way but any form of IPC is potentially problematic: consider what happens if the thread is writing to a socket borrowed from a pool, or to a disk file.

Not impossible to deal with but everything you do needs to be designed with cancellation-at-any-point in mind, it doesn't seem worth it to me.

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

>>verdag+(OP)
SQL comes to mind.