FAQ
`uname -a`: Linux testing-worker-linux-docker-545af3bd-3302-linux-3
3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64
x86_64 GNU/Linux

`lsb release -a`: Description: Ubuntu 12.04.5 LTS

`go version`: go version go1.4 linux/amd64

the test is run under `--race --cpu 1,2,4`

I added the trace flag and got this:
```
2015/06/25 15:58:49 TestWaitTestStress start
gc3(1): 2+0+140+1 us, 0 -> 0 MB, 338 (392-54) objects, 6 goroutines, 32/0/0
sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc4(1): 1+0+132+0 us, 0 -> 0 MB, 678 (877-199) objects, 6 goroutines,
41/23/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc5(1): 1+0+141+0 us, 0 -> 0 MB, 1135 (1583-448) objects, 6 goroutines,
42/34/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc6(1): 1+0+162+0 us, 0 -> 0 MB, 1786 (2593-807) objects, 6 goroutines,
49/34/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc7(1): 1+0+232+0 us, 0 -> 0 MB, 2548 (3880-1332) objects, 6 goroutines,
59/42/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc8(1): 1+1+365+0 us, 0 -> 0 MB, 5270 (7240-1970) objects, 6 goroutines,
88/52/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc9(1): 2+1+362+1 us, 0 -> 1 MB, 10159 (13796-3637) objects, 6 goroutines,
140/80/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
gc10(1): 2+1+568+0 us, 0 -> 1 MB, 12398 (19316-6918) objects, 6 goroutines,
168/133/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
--- FAIL: TestWaitTestStress (0.20s)
wait_time_test.go:67: cannot receive from ch as expected
```

If any channel failed to receive the response in 10ms, the test fails.
On Wed, Jun 24, 2015 at 7:01 PM, Brad Fitzpatrick wrote:

OS? Arch? Go version?

I assume linux-amd64 from coreos.com and -race. But which Go version?

I wonder if you're just generating lots of garbage and causing the GC to
run, making that time.After channel 10000 times.


On Wed, Jun 24, 2015 at 11:27 PM, Yicheng Qin wrote:

Hi all,

We observe at least 10ms delay before receiving message from closed
buffered channel. We met this when we run some code basically like this:

```
chs := make([]chan struct{}, 10000)
// init
for i := range chs {
chs[i] = make(chan struct{}, 1)
}
// close
for _, ch := range chs {
close(ch)
}
// receive
for _, ch := range chs {
select {
case <-ch:
case <-time.After(10 * time.Millisecond):
t.Fatalf("")
}
}
```

The test environment is under --cpu 4 --race on travis(2 bursted cpu)
when running `go test` for the whole test set. After I adjust the timeout
to 1s, I didn't observe this behavior anymore. Is this behavior expected?

I check the spec, which says that `After calling close, and after any
previously sent values have been received, receive operations will return
the zero value for the channel's type without blocking.`

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 7 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 24, '15 at 9:27p
activeJun 25, '15 at 10:13p
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase