On Wed, Apr 5, 2017 at 2:29 PM 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?
>
>
>
Most systems with really precise
On Wed, Apr 5, 2017 at 10:22 AM, Tejas Manohar 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.
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 wrote:
On W
On Wed, Apr 5, 2017 at 12:02 AM, 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 oth
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?
Just curious. Thanks!
--
You received this message because you are subscribed t
