Nov 16, 2015, 1:41:24 PM11/16/15
to Russ Cox, Peter Waller, golang-dev, Caleb Spare
On 16 November 2015 at 17:32, Russ Cox <r...@golang.org
> On Mon, Nov 16, 2015 at 10:21 AM, Peter Waller <pe...@scraperwiki.com
>> Your email made me aware of the problem and helped me discover a race in
>> some code I recently wrote that uses Timer in exactly this manner. This
>> hazard is not clear from the documentation. I had figured out that I needed
>> to make non-blocking read from timer.C after calling Stop(), but not that
>> delivery might come an arbitrarily long time after Stop().
> It's not arbitrarily long. If Stop returns false and you haven't received
> from timer.C yet, then a plain "<-timer.C" will run quickly, subject only to
> scheduling delays.
Ok, of course, it's clear in retrospect: it's not possible to make a
Timer.Reset substitute that works as I'd like (convenient for fixing
bugs in existing code), but at least it's possible
to work around the situation by stopping the timer when it's known that
the timer has expired.
I still think the API is harder to use for this common case than it should
be. Perhaps we can mitigate the situation by documenting this