Hello,
I found that if I use timeout mixed with another chan which is heavily
communicated with other goroutines, it could lead to dead lock or something
inside select
Here is the codes:
for {
select {
case x := <-ch:
// handling business logic begin (about 38+ message pushed to this chan at
the same time)
...
// handling business logic end
* case <-btimeout:*
* stop <- 1*
* stats(requests, done, fails, time.Duration(bench_timeout), starttimes,
endtimes)*
* return*
* case <-timeout:*
* switch {*
* case totals == 0:*
* stop <- 1*
* stats(requests, done, fails, time.Duration(duration), starttimes,
endtimes)*
* return*
* default:*
* stop <- 0*
* init_timeout_trigger(duration, timeout)*
}
}
When I run the code and the communication between channel "ch" up to 4600+,
the "select" handling will run into dead
When I commented the two case of "*btimeout*" and "*timeout*", then
everything will be OK
So, I suspect if the "select" keyword may have bug in scheduling each true
case fairly while timeout event not triggered at all
Could anyone explain to me if it is a bug with "select" or just my usage is
incorrect? thanks.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
