[dmytrish]

The problem with that approach in Go is that BEAM embraces the shared-nothing approach, and the Go runtime is quite promiscuous about sharing mutable data. I am afraid that introducing non-deterministic preemptive stops will just make Go concurrency a mess similar to the mutex/conditionals mess they've been trying to avoid.

[jerf]

"I am afraid that introducing non-deterministic preemptive stops will just make Go concurrency a mess similar to the mutex/conditionals mess they've been trying to avoid."

They already took a few steps inside of Go to try to ensure that concurrency is quite non-deterministic. Even very simple, naive code like

    func main() {
        for i := 0; i < 2; i++ {
            go func(j int) {
                fmt.Println("First", j)
                fmt.Println("Second", j)
            }(i)
        }
        time.Sleep(100*time.Millisecond)
    }

will very frequently produce different results; I just ran that four times and got four different results. This is good, because it tends to bring bugs to the forefront more quickly, rather than having a almost-but-not-quite-deterministic model as has been the case in many other environments.

(Yes, I know sleep is not production-quality here, just trying to keep it simpler than several more lines for a proper waitgroup usage.)

I doubt there's a lot of code written at the Go level that would explode if you suddenly ran it with a pre-emptive runtime that isn't already exploding. As the proposal discusses, there's a lot of issues down at the runtime level, but at the layer of abstraction presented by the language itself I wouldn't expect a lot of problems. Non-zero, and even then, it would still be things that are technically already bugs. And Go code is already running concurrently all the time in the real world. I'm not even sure how I'd construct an example that runs correctly in the current runtime but fails with true pre-emption.

[notheguyouthink]

> will very frequently produce different results; I just ran that four times and got four different results. This is good, because it tends to bring bugs to the forefront more quickly, rather than having a almost-but-not-quite-deterministic model as has been the case in many other environments.

I concur, they do this with maps too. It led to discovering a bug in our system where order was being implicitly depended on via a JSON Object -> Map conversion. Go randomized the map key order when iterated over, revealing the logic bug.

[lloeki]

> They already took a few steps inside of Go to try to ensure that concurrency is quite non-deterministic

I would not be surprised as they are already proactively ensuring things like map ordering are randomised so that people just can't rely on some deterministic ordering: run the example code here[0] multiple times and it produces not just a seemingly random result (as would be for a typical hash table) but a truly different result for each run.

[0]: https://nathanleclaire.com/blog/2014/04/27/a-surprising-feat...

[kardianos]

Yes, map iteration is explicitly randomized for just this thing.

[mseepgood]

Mutating shared state without synchronization is a bug with or without this proposal. Goroutines already run on potentially different OS threads or processors with the current m:n scheduler implementation.

[masklinn]

> I am afraid that introducing non-deterministic preemptive stops will just make Go concurrency a mess similar to the mutex/conditionals mess they've been trying to avoid.

It already is exactly that (Go already does m:n scheduling, so while your routine currently can't get interrupted between two function calls, two goroutines running on different OS threads can manipulate the same mutable state without synchronisation and make a mess of it), it's just that you don't necessarily notice.

[dilap]

Go code is not shared-state safe in the way that, say, Python generators are. And with the -race compile flag, it does a pretty good job of detecting violations so you can fix them.

So I think Go code should be unaffected by this change.