I'm not going to debate it since I am not really volunteering to fix
the docs right now, anyway :) My sense is that when I want to know
how to use something, I run `go doc` on it. The doc as it stands says
"don't do it" when the reality has an extra "unless ..." clause.
Thanks for the guidance!
On Wed, Jan 25, 2017 at 11:32 AM, Tim Hockin wrote:
> Better to have a documented race than a potential hang, though, yeah?
> If it delivers and then I Stop(), drain, Reset(), I might lose the
> race, have the channel read by the concurrent receiver, and and just
> block here. Or am I missing som
Better to have a documented race than a potential hang, though, yeah?
If it delivers and then I Stop(), drain, Reset(), I might lose the
race, have the channel read by the concurrent receiver, and and just
block here. Or am I missing some other nuance here?
On Wed, Jan 25, 2017 at 11:21 AM, Ian L
On Wed, Jan 25, 2017 at 10:30 AM, Tim Hockin wrote:
> Thanks! That makes sense. Does it make sense to update the docs to
> show the "select-with-default" mode of draining the channel instead?
I guess I don't think so, as there is still a potential race with the
other receive. I mean, we can ma
Thanks! That makes sense. Does it make sense to update the docs to
show the "select-with-default" mode of draining the channel instead?
On Wed, Jan 25, 2017 at 10:20 AM, Ian Lance Taylor wrote:
> On Wed, Jan 25, 2017 at 9:34 AM, 'Tim Hockin' via golang-nuts
> wrote:
>> I'm not convinced that t
On Wed, Jan 25, 2017 at 9:34 AM, 'Tim Hockin' via golang-nuts
wrote:
> I'm not convinced that the docs quite cover the case I am looking, so
> I am posting here.
>
> https://golang.org/pkg/time/#Timer.Reset says "This should not be done
> concurrent to other receives from the Timer's channel" but
