FAQ
This program (run locally) starts 1000000 go routines each of which
starts a ticker then closes the goroutines down again in an orderly fashion

http://play.golang.org/p/zy5X4hAq0I

It sleeps at the end so you can run top or equivalent. If you do you'll
see it using a lot of CPU at this point. kill the process with -QUIT
and you'll find that this is the only goroutine of significance running.

goroutine 100005 [running]:
runtime.siftdownTimer(0xe0a)
  /usr/local/go/src/runtime/time.go:265 +0xbf fp=0xc21641a768 sp=0xc21641a718
runtime.timerproc()
  /usr/local/go/src/runtime/time.go:172 +0x1cb fp=0xc21641a7e0
sp=0xc21641a768
runtime.goexit()
  /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc21641a7e8
sp=0xc21641a7e0
created by runtime.addtimerLocked
  /usr/local/go/src/runtime/time.go:113 +0x1ba

It appears that all those tickers got leaked and the code is spending
all the CPU keeping them up to date.

Naively I was expecting that once the goroutines returned they would be
garbage collected but that doesn't appear to be the case.

This is easy to fix of course (with NewTicker and Stop()), but is it
expected that the tickers aren't garbage collected?

--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nick Craig-Wood at Jul 7, 2015 at 8:05 am
    Replying to myself... I see this has been discussed before

    https://github.com/golang/go/issues/8001

    This resulted in "Stop the ticker to release associated resources."
    being added to the NewTicker documents.

    I wonder whether something similar needs to go in the docs for time.Tick
    which says

    "Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker."

    It doesn't say why you might need to shut down the ticker.
    On 07/07/15 08:26, Nick Craig-Wood wrote:
    This program (run locally) starts 1000000 go routines each of which
    starts a ticker then closes the goroutines down again in an orderly fashion

    http://play.golang.org/p/zy5X4hAq0I

    It sleeps at the end so you can run top or equivalent. If you do you'll
    see it using a lot of CPU at this point. kill the process with -QUIT
    and you'll find that this is the only goroutine of significance running.

    goroutine 100005 [running]:
    runtime.siftdownTimer(0xe0a)
    /usr/local/go/src/runtime/time.go:265 +0xbf fp=0xc21641a768 sp=0xc21641a718
    runtime.timerproc()
    /usr/local/go/src/runtime/time.go:172 +0x1cb fp=0xc21641a7e0
    sp=0xc21641a768
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc21641a7e8
    sp=0xc21641a7e0
    created by runtime.addtimerLocked
    /usr/local/go/src/runtime/time.go:113 +0x1ba

    It appears that all those tickers got leaked and the code is spending
    all the CPU keeping them up to date.

    Naively I was expecting that once the goroutines returned they would be
    garbage collected but that doesn't appear to be the case.

    This is easy to fix of course (with NewTicker and Stop()), but is it
    expected that the tickers aren't garbage collected?

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Jul 7, 2015 at 7:49 pm
    They can probably just read the NewTicker docs too, since it does say it's
    a wrapper for it.

    But feel free to send Rob a documentation CL if you have non-intrusive
    wording updates.

    On Tue, Jul 7, 2015 at 1:05 AM, Nick Craig-Wood wrote:

    Replying to myself... I see this has been discussed before

    https://github.com/golang/go/issues/8001

    This resulted in "Stop the ticker to release associated resources."
    being added to the NewTicker documents.

    I wonder whether something similar needs to go in the docs for time.Tick
    which says

    "Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker."

    It doesn't say why you might need to shut down the ticker.
    On 07/07/15 08:26, Nick Craig-Wood wrote:
    This program (run locally) starts 1000000 go routines each of which
    starts a ticker then closes the goroutines down again in an orderly fashion
    http://play.golang.org/p/zy5X4hAq0I

    It sleeps at the end so you can run top or equivalent. If you do you'll
    see it using a lot of CPU at this point. kill the process with -QUIT
    and you'll find that this is the only goroutine of significance running.

    goroutine 100005 [running]:
    runtime.siftdownTimer(0xe0a)
    /usr/local/go/src/runtime/time.go:265 +0xbf fp=0xc21641a768
    sp=0xc21641a718
    runtime.timerproc()
    /usr/local/go/src/runtime/time.go:172 +0x1cb fp=0xc21641a7e0
    sp=0xc21641a768
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc21641a7e8
    sp=0xc21641a7e0
    created by runtime.addtimerLocked
    /usr/local/go/src/runtime/time.go:113 +0x1ba

    It appears that all those tickers got leaked and the code is spending
    all the CPU keeping them up to date.

    Naively I was expecting that once the goroutines returned they would be
    garbage collected but that doesn't appear to be the case.

    This is easy to fix of course (with NewTicker and Stop()), but is it
    expected that the tickers aren't garbage collected?

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Craig-Wood at Jul 9, 2015 at 10:05 am
    Something like this?

    Before
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker.

    After
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Note that this leaks associated resources; use
    NewTicker and Stop to avoid that.

    On 07/07/15 20:49, Brad Fitzpatrick wrote:
    They can probably just read the NewTicker docs too, since it does say
    it's a wrapper for it.

    But feel free to send Rob a documentation CL if you have non-intrusive
    wording updates.


    On Tue, Jul 7, 2015 at 1:05 AM, Nick Craig-Wood wrote:

    Replying to myself... I see this has been discussed before

    https://github.com/golang/go/issues/8001

    This resulted in "Stop the ticker to release associated resources."
    being added to the NewTicker documents.

    I wonder whether something similar needs to go in the docs for time.Tick
    which says

    "Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker."

    It doesn't say why you might need to shut down the ticker.
    On 07/07/15 08:26, Nick Craig-Wood wrote:
    This program (run locally) starts 1000000 go routines each of which
    starts a ticker then closes the goroutines down again in an
    orderly fashion
    http://play.golang.org/p/zy5X4hAq0I

    It sleeps at the end so you can run top or equivalent. If you do you'll
    see it using a lot of CPU at this point. kill the process with -QUIT
    and you'll find that this is the only goroutine of significance running.
    goroutine 100005 [running]:
    runtime.siftdownTimer(0xe0a)
    /usr/local/go/src/runtime/time.go:265 +0xbf fp=0xc21641a768
    sp=0xc21641a718
    runtime.timerproc()
    /usr/local/go/src/runtime/time.go:172 +0x1cb fp=0xc21641a7e0
    sp=0xc21641a768
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc21641a7e8
    sp=0xc21641a7e0
    created by runtime.addtimerLocked
    /usr/local/go/src/runtime/time.go:113 +0x1ba

    It appears that all those tickers got leaked and the code is spending
    all the CPU keeping them up to date.

    Naively I was expecting that once the goroutines returned they would be
    garbage collected but that doesn't appear to be the case.

    This is easy to fix of course (with NewTicker and Stop()), but is it
    expected that the tickers aren't garbage collected?

    --
    Nick Craig-Wood <nick@craig-wood.com -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com
    For more options, visit https://groups.google.com/d/optout.

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Jul 9, 2015 at 8:42 pm
    That's a little scary sounding and not quite accurate. And you removed the
    good part ("Useful for clients that have no need to shut down the ticker."

    File a bug at least? We can discuss there. Or send a CL might be easier and
    others can revise there.


    On Thu, Jul 9, 2015 at 4:04 AM, Nick Craig-Wood wrote:

    Something like this?

    Before
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker.

    After
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Note that this leaks associated resources; use
    NewTicker and Stop to avoid that.

    On 07/07/15 20:49, Brad Fitzpatrick wrote:
    They can probably just read the NewTicker docs too, since it does say
    it's a wrapper for it.

    But feel free to send Rob a documentation CL if you have non-intrusive
    wording updates.


    On Tue, Jul 7, 2015 at 1:05 AM, Nick Craig-Wood <nick@craig-wood.com
    wrote:

    Replying to myself... I see this has been discussed before

    https://github.com/golang/go/issues/8001

    This resulted in "Stop the ticker to release associated resources."
    being added to the NewTicker documents.

    I wonder whether something similar needs to go in the docs for time.Tick
    which says

    "Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker."

    It doesn't say why you might need to shut down the ticker.
    On 07/07/15 08:26, Nick Craig-Wood wrote:
    This program (run locally) starts 1000000 go routines each of which
    starts a ticker then closes the goroutines down again in an
    orderly fashion
    http://play.golang.org/p/zy5X4hAq0I

    It sleeps at the end so you can run top or equivalent. If you do you'll
    see it using a lot of CPU at this point. kill the process with
    -QUIT
    and you'll find that this is the only goroutine of significance running.
    goroutine 100005 [running]:
    runtime.siftdownTimer(0xe0a)
    /usr/local/go/src/runtime/time.go:265 +0xbf fp=0xc21641a768
    sp=0xc21641a718
    runtime.timerproc()
    /usr/local/go/src/runtime/time.go:172 +0x1cb fp=0xc21641a7e0
    sp=0xc21641a768
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1
    fp=0xc21641a7e8
    sp=0xc21641a7e0
    created by runtime.addtimerLocked
    /usr/local/go/src/runtime/time.go:113 +0x1ba

    It appears that all those tickers got leaked and the code is
    spending
    all the CPU keeping them up to date.

    Naively I was expecting that once the goroutines returned they would be
    garbage collected but that doesn't appear to be the case.

    This is easy to fix of course (with NewTicker and Stop()), but is
    it
    expected that the tickers aren't garbage collected?

    --
    Nick Craig-Wood <nick@craig-wood.com > -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com
    For more options, visit https://groups.google.com/d/optout.

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Craig-Wood at Jul 10, 2015 at 9:35 pm
    I've filed as issue here https://github.com/golang/go/issues/11662

    I would do a CL but I'm just about to go on vacation and don't want to
    dump it and run!

    I'll examine the issue when I get back and submit a CL is no-one got
    there before me.
    On 09/07/15 21:42, Brad Fitzpatrick wrote:
    That's a little scary sounding and not quite accurate. And you removed
    the good part ("Useful for clients that have no need to shut down the
    ticker."

    File a bug at least? We can discuss there. Or send a CL might be easier
    and others can revise there.



    On Thu, Jul 9, 2015 at 4:04 AM, Nick Craig-Wood wrote:

    Something like this?

    Before
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker.

    After
    Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Note that this leaks associated resources; use
    NewTicker and Stop to avoid that.

    On 07/07/15 20:49, Brad Fitzpatrick wrote:
    They can probably just read the NewTicker docs too, since it does say
    it's a wrapper for it.

    But feel free to send Rob a documentation CL if you have non-intrusive
    wording updates.


    On Tue, Jul 7, 2015 at 1:05 AM, Nick Craig-Wood <nick@craig-wood.com > wrote:

    Replying to myself... I see this has been discussed before

    https://github.com/golang/go/issues/8001

    This resulted in "Stop the ticker to release associated
    resources."
    being added to the NewTicker documents.

    I wonder whether something similar needs to go in the docs for time.Tick
    which says

    "Tick is a convenience wrapper for NewTicker providing access to the
    ticking channel only. Useful for clients that have no need to shut down
    the ticker."

    It doesn't say why you might need to shut down the ticker.
    On 07/07/15 08:26, Nick Craig-Wood wrote:
    This program (run locally) starts 1000000 go routines each
    of which
    starts a ticker then closes the goroutines down again in an
    orderly fashion
    http://play.golang.org/p/zy5X4hAq0I

    It sleeps at the end so you can run top or equivalent. If
    you do
    you'll
    see it using a lot of CPU at this point. kill the process
    with -QUIT
    and you'll find that this is the only goroutine of significance running.
    goroutine 100005 [running]:
    runtime.siftdownTimer(0xe0a)
    /usr/local/go/src/runtime/time.go:265 +0xbf
    fp=0xc21641a768
    sp=0xc21641a718
    runtime.timerproc()
    /usr/local/go/src/runtime/time.go:172 +0x1cb
    fp=0xc21641a7e0
    sp=0xc21641a768
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1
    fp=0xc21641a7e8
    sp=0xc21641a7e0
    created by runtime.addtimerLocked
    /usr/local/go/src/runtime/time.go:113 +0x1ba

    It appears that all those tickers got leaked and the code is
    spending
    all the CPU keeping them up to date.

    Naively I was expecting that once the goroutines returned they would be
    garbage collected but that doesn't appear to be the case.

    This is easy to fix of course (with NewTicker and Stop()),
    but is it
    expected that the tickers aren't garbage collected?

    --
    Nick Craig-Wood <nick@craig-wood.com
    -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com
    For more options, visit https://groups.google.com/d/optout.

    --
    Nick Craig-Wood <nick@craig-wood.com -- http://www.craig-wood.com/nick

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 7, '15 at 7:26a
activeJul 10, '15 at 9:35p
posts6
users2
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase