<pre class="notranslate">See code here:
<a href="http://play.golang.org/p/50TI5VuWHN" rel="nofollow">http://play.golang.org/p/50TI5VuWHN</a>

What is the expected output?
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMloop: tick tsecs=1.001247, secs=1.001247, cnt=32412156
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMloop: tick tsecs=2.002406, secs=1.001159, cnt=34743305
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMloop: tick tsecs=3.001494, secs=0.999088, cnt=3168060

What do you see instead?
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM ...


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g


Which operating system are you using?
MacOS X 10.7.5


Which version are you using?  (run 'go version')
1.0.3
1.1 (go version devel +13e00572ed0b Thu Apr 18 17:37:21 2013 -0700 darwin/amd64)

Please provide any additional information below.
With Go 1.0.3 this program works the same with GOMAXPROCS=1 or GOMAXPROC &gt; 1
With Go 1.1 this program works the same as 1.0.3 when GOMAXPROC &gt; 1
With Go 1.1 when GOMAXPROC=1 the Ticker never ticks.

This represents a change in behavior from 1.0.3 to 1.1.

In my mental model of the Go runtime, at least when GOMAXPROCS=1, the "select"
statement *must* call the scheduler to allow other goroutines to run. If this is not the
case, then it should be documented what one needs to do in order to get scheduling to
occur.

Questions:

1. Is it really the case that I must insert a call to runtime.Gosched() to get the
correct behavior in Go 1.1? I find that a very unappealing solution to say the least.

2. Are there any guarantees at the language reference specification level of what one
must do to prevent goroutine scheduling starvation, especially when GOMAXPROCS=1? If
not, should there be?

This simple program was distilled down from a larger program that does I/O and compute
in the spot where the example does cnt++.. The larger program is collecting I/O metrics
and the Ticker is used to decide when to collect the metrics and reset the them. With Go
1.1 and GOMAXPROCS=1 I saw some bizarre behavior. The Ticker (set at 1s duration) would
tick fine for 300 seconds and then it would stop for a long time. Occasionally it would
send something down the channel. Really it was very strange.</pre>
<p dir="auto">by <strong>sjbogdan</strong>:</p>
<pre class="notranslate">A 64-bit executable consumes 540 MB on "hello world" project on startup
32-bit executable (on x86-64 system) uses acceptable amount of memory ~ 9 MB

Version affected : v1.1beta2 and v1.1rc1 compiles

&gt; go version
go version devel +bea6199b09ea Tue Apr 30 17:47:39 2013 -0700 windows/amd64

Code : any hello world program compiled with 6g
Example :
package main

import "time"

func main () {
    time.Sleep ( 1 * time.Minute )
}

---
See attachments

Additional information :
Windows 8 ( x86-64 ) Enterprize
Never used intaller, extracted from zip and set up GOROOT &amp; GOPATH</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/5402/0/ResMonitor.png" rel="nofollow">ResMonitor.png</a> (18103 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/5402/0/PM_amd64.png" rel="nofollow">PM_amd64.png</a> (19327 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/5402/0/PM1_amd64.png" rel="nofollow">PM1_amd64.png</a> (9353 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/5402/0/PM_386.png" rel="nofollow">PM_386.png</a> (19339 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/5402/0/PM1_386.png" rel="nofollow">PM1_386.png</a> (9393 bytes)</li>
</ol>