Closing channels on timer Stop()
Vadik Vygonets
When a time.Timer is stopped, it doesn't close the channel, which, as
far as I understand, means that the routine waiting on the channel
will hang forever. (Correct me if I'm wrong.) So to kill it, I
create another channel and do:
for {
select {
case <-s.ticker.C:
f()
case <-s.headShot:
return
}
}
Why is that? Closing the channel seems like such a natural thing to
do that if it weren't done, the authors probably had a very good
reason. (And the tests expect this behaviour, too.)
While we're at the subject, can we have a version of NewTicker() that
sets r.when and r.period to different values? (At the moment I solve
this with a Timer that runs a Ticker when it expires.)
(No, I'm not writing cron.)
Thanks,
Vadik.
Ian Lance Taylor
> When a time.Timer is stopped, it doesn't close the channel, which, as
> far as I understand, means that the routine waiting on the channel
> will hang forever.
The usual idiom would be to use a select statement waiting for either a
Timer channel or some other channel. If data arrives on the other
channel, you no longer care about the Timer, so you stop it. I'm not
sure when you would use a Timer that you stop while some goroutine is
waiting on it.
Ian
Vadik Vygonets
> The usual idiom would be to use a select statement waiting for either a
> Timer channel or some other channel. If data arrives on the other
> channel, you no longer care about the Timer, so you stop it.
So I should stop it from within the switch? Got it, thanks.
> I'm not
> sure when you would use a Timer that you stop while some goroutine is
> waiting on it.
It's a periodic schedule that I may want to cancel at some point.
Thanks for the explanation,
Vadik.
Ian Lance Taylor
I suppose I don't see anything wrong with having a Timer, or especially
a Ticker, close the channel when the Stop method is called. Could you
file an issue for that? Thanks.
Ian
Andrew Gerrand
On Friday, December 16, 2011 5:01:50 AM UTC+11, Ian Lance Taylor wrote:
Vadik Vygonets <uni...@gmail.com> writes:
> On Dec 15, 8:24 am, Ian Lance Taylor <i....@google.com> wrote:
>
>> I'm not
>> sure when you would use a Timer that you stop while some goroutine is
>> waiting on it.
>
> It's a periodic schedule that I may want to cancel at some point.I suppose I don't see anything wrong with having a Timer, or especially
a Ticker, close the channel when the Stop method is called. Could you
file an issue for that? Thanks.
Andrew Gerrand
Vadik Vygonets
> I suppose I don't see anything wrong with having a Timer, or especially
> a Ticker, close the channel when the Stop method is called. Could you
> file an issue for that? Thanks.
http://codereview.appspot.com/5491059
Though now I'm having doubts: it changes the behaviour too much.
Vadik.
roger peppe
> The one downside I can see is that currently you can do
> t.Stop()
> close(t.C)
> to get the behavior discussed in this thread.
two reasons you can't do that:
- t.C is a receive-only channel, which means you can't close it.
- even if you could, the Stop is not synchronous, so you might
get a panic when the ticker tries to send to the channel after
you've closed it.
i'd like it if Ticker closed the channel on Stop.
Vadik Vygonets
> i'd like it if Ticker closed the channel on Stop.
Not gonna happen, please see the issue for details.
Vadik.
