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.
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.
