On Wed, Apr 5, 2017 at 10:22 AM, Tejas Manohar <te...@segment.com> wrote: > Thanks! That makes sense. For tickers, would you expect there to be loud > failures (e.g. panics) or silent delays under high load? Seems like silent > delays. I think this is acceptable for Go but am more wondering if I'm > missing anything.
Silent delays. Ian > On Wed, Apr 5, 2017 at 6:26 AM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Wed, Apr 5, 2017 at 12:02 AM, <te...@segment.com> wrote: >> > What guarantees do Golang's timers (e.g. time.After, time.Sleep) >> > provide? If >> > you're using lots of timers concurrently, what (if anything) could cause >> > them to misbehave (e.g. delay)? What are they bottlenecked by? >> >> They don't provide any guarantees other than best effort. Go is not a >> hard real time programming language. >> >> In the current implementation, if you are adding and/or removing a >> very large number of timers from different goroutines running >> concurrently, then I think the bottleneck would be the single lock on >> runtime.timers. If you have a very large number of tickers, then I >> think the bottleneck would be the runtime managing the heap of timers >> that keeps the next one to fire on the top. Those are just my >> guesses, though, I haven't tried to verify them. >> >> Ian > > -- > > Best regards, > > Tejas Manohar -- 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.
