runtime: golang scheduler is not preemptive - it's cooperative?

[GoranP]

If you run this code with only one go routine:

package main

import "fmt"
import "runtime"
import "time"

func cpuIntensive(p *int) {
  for i := 1; i <= 100000000000; i++ {
    *p = i
  }
}

func main() {
  runtime.GOMAXPROCS(1)

  x := 0
  go cpuIntensive(&x)

  time.Sleep(100 * time.Millisecond)

  // printed only after cpuIntensive is completely finished
  fmt.Printf("x = %d.\n", x)
}

Scheduler is paralized, and Printf is NOT printed after 100ms as expected, but after all job is done in cpuintensive() go routine.

But if programmer insert runtime.Gosched() in intensive for loop of routine, cooperative scheduler works fine.

Is this by design or are there plans to make Golang scheduler preemptive?

[davecheney]

Is this by design or are there plans to make Golang scheduler preemptive?

It is by design. There are no plans to make the scheduler fully preemtive, in normal situations, this is not a problem.

[RLH]

The traditional work around is to unroll the loop and add a Gosched. If
there are real world scenarios and available resources the compiler could
be taught how to do the transformation.

On Mon, Jun 29, 2015 at 7:19 AM, Dave Cheney notifications@github.com
wrote:

Is this by design or are there plans to make Golang scheduler preemptive?

It is by design. There are no plans to make the scheduler fully preemtive,
in normal situations, this is not a problem.

—
Reply to this email directly or view it on GitHub
#11462 (comment).

[aclements]

@GoranP, you can think of the Go scheduler as being partially preemptive. It's by no means fully cooperative, since user code generally has no control over scheduling points, but it's also not able to preempt at arbitrary points. Currently, the general rule is that it can preempt at function calls, since at that point there's very little state to save or restore, which makes preemption very fast and dramatically simplifies some aspects of garbage collection. Your loop happens to contain none of these controlled preemption points, which is why the scheduler can't preempt it, but as @davecheney mentioned, this is fairly uncommon in real code (though by no means unheard of). We would like to detect loops like this and insert preemption points, but that work just hasn't happened yet. The issue for tracking that work (or, at least, the desire to do it :) is #10958.

Duplicate of #10958.

[GoranP]

Thx guys for clarification.