An empty for{} will block large slice allocation in another goroutine, even with GOMAXPROCS > 1 ?

[yaofu1986]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.6.1 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/yaofu/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

package main

import (
    "runtime"
)

func work() {
    println("before")
    s := make([]int, 6000000)
    println("after")
    s[0] = 1
}

func main() {
    runtime.GOMAXPROCS(4)

    //work()   // This is OK. Very quick.
    go work()

    for {
    }
}

PS: I know for{} busy wait is no good. But I'm curious to know the underlying reason.

What did you expect to see?

following print:

before
after

What did you see instead?

following printed:

before

[randall77]

Go has a cooperative, not preemptive, scheduler. The for{} loop never reaches a preemption point, so a garbage collection cannot complete.
Dup of #10958

[ianlancetaylor]

If you want to block forever, use select {}.

[quentinmit]

Can/should the compiler automatically turn for {} into select {}?

On Sep 21, 2016 09:11, "Ian Lance Taylor" notifications@github.com wrote:

If you want to block forever, use select {}.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17174 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHEMWI0mZF8FIy7xSwyfhN07SZLFkxNks5qsS0BgaJpZM4KCasB
.

[ianlancetaylor]

It could but I don't think it's worth it. Nobody writes for {} in real code.

[minux]

The for {} problem is only one special case of a non-preemptible loop. I don't think the compiler should handle this one case but not the others. However, handling the general problem is very hard because sometimes people do write such tight loops to crunch data, for example, and the compiler shouldn't insert preemption points into such deliberate tight loops. I couldn't think of any valid use of for {} except toy examples, so I think the status quo is fine.