Home  >  Article  >  Backend Development  >  How Do Goroutines Behave Differently Between Go Playground and Local Machine?

How Do Goroutines Behave Differently Between Go Playground and Local Machine?

Mary-Kate Olsen
Mary-Kate OlsenOriginal
2024-10-23 17:42:24452browse

How Do Goroutines Behave Differently Between Go Playground and Local Machine?

Discrepancies between Go Playground and Go on my local machine

Issue: Goroutines in Go Playground vs. local machine

To clarify misunderstandings about goroutines, this code was run in the Go Playground:

<code class="go">package main

import (
    "fmt"
)

func other(done chan bool) {
    done <- true
    go func() {
        for {
            fmt.Println("Here")
        }
    }()
}

func main() {
    fmt.Println("Hello, playground")
    done := make(chan bool)
    go other(done)
    <-done
    fmt.Println("Finished.")
}</code>

In the Go Playground, it resulted in an error: "Process took too long." This suggests that the goroutine created within other runs indefinitely.

However, running the same code locally produced the immediate output:

<code class="go">Hello, playground.
Finished.</code>

This implies that the goroutine within other exits when the main goroutine finishes.

Explanation

The disparity is due to the default value of GOMAXPROCS.

On the Go Playground, GOMAXPROCS is set to 1. This means that only one goroutine can run at a time. When the goroutine created within other does not block (e.g., by waiting on a channel), the scheduler will not switch to other goroutines.

Since the main goroutine is blocking on the done channel, the scheduler switches to the goroutine within other. Then, the goroutine within other launches another goroutine with an endless loop. Since GOMAXPROCS is 1, the main goroutine is not continued, and the endless loop continues running, leading to the timeout.

On the local machine, GOMAXPROCS typically defaults to the number of CPU cores (e.g., 4 or 8). This allows multiple goroutines to run concurrently. When the main goroutine blocks on the done channel, the scheduler switches to another goroutine. This could be the goroutine within other or the goroutine running the endless loop.

Since the main goroutine will eventually finish, the endless loop will no longer be running. Therefore, the program will terminate normally, without waiting for the endless loop to complete.

Conclusion

When running goroutines in the Go Playground, it's important to consider the default value of GOMAXPROCS. To simulate multi-goroutine concurrency, explicitly set GOMAXPROCS to a higher value, such as runtime.GOMAXPROCS(2). In local execution, GOMAXPROCS's default setting typically allows for expected concurrency behavior.

The above is the detailed content of How Do Goroutines Behave Differently Between Go Playground and Local Machine?. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn