On Thu, Dec 8, 2016 at 7:44 PM, Freeman Feng <[email protected]> wrote: > > 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.
A bug in select is fairly unlikely at this point. Can you show us a complete program that demonstrates the failure? In particular, what is reading from the stop channel? Ian -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
