Grokbase › Groups › Go › golang-nuts › April 2014
FAQ
Hi,
is there are reason to mange pool of running goroutines ?
use case is network server that receive requests and launch goroutines (
short lived ) to handle requests.
does goroutines generate garbage ?

tanks in advance,

Djadala



--
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

  • Walu Zhang at Apr 30, 2014 at 9:08 am ⇧
    i think you'd like to open a new goroutine

    On Wed, Apr 30, 2014 at 4:32 PM, wrote:

    Hi,
    is there are reason to mange pool of running goroutines ?
    use case is network server that receive requests and launch goroutines (
    short lived ) to handle requests.
    does goroutines generate garbage ?

    tanks in advance,

    Djadala



    --
    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.


    --
    ---------
    Hi, I'm walu
    http://weibo.com/walu
    http://www.walu.cc

    --
    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.
  • Benjamin Measures at Apr 30, 2014 at 9:24 am ⇧

    On Wednesday, 30 April 2014 09:32:09 UTC+1, dja...@gmail.com wrote:
    is there are reason to mange pool of running goroutines ?
    Pools are useful for when you need to bound the number of running
    goroutines. They can also help with latency, since there's less chance of
    starvation (where the number of goroutines is bounded).

    use case is network server that receive requests and launch goroutines (
    short lived ) to handle requests.
    Since goroutines are cheap, they lend well to being (relatively)
    short-lived.

    does goroutines generate garbage ?
    Afaik they don't generate garbage in of themselves, just allocating 8kb of
    stack space. This isn't garbage collected in the traditional sense though.


    http://golang.org/doc/faq#goroutines

    --
    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.
  • Dmitry Vyukov at Apr 30, 2014 at 1:09 pm ⇧

    On Wed, Apr 30, 2014 at 12:32 PM, wrote:
    Hi,
    is there are reason to mange pool of running goroutines ?
    use case is network server that receive requests and launch goroutines (
    short lived ) to handle requests.
    does goroutines generate garbage ?

    Goroutine start/end does not create garbage.
    In fact, creating a goroutine can be faster/more scalable, because (1)
    goroutine creation is a purely local action while sending/receiving
    from a single channel is inherently centralized and (2) distribution
    of runnable goroutines can be more efficient than channel-based
    load-balancing because it benefit from batching while channels are
    inherently one-by-one.

    --
    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.
  • Thomas Bushnell, BSG at Apr 30, 2014 at 6:52 pm ⇧
    As others have said, better to spin a new goroutine for each one.

    If you want to limit the total number of concurrent requests, and you were
    using the goroutines for that, I usually use a buffered channel. Stick N
    things on the channel, and goroutines pull one off the channel and hold it
    as a token meaning they're allowed to do work.

    On Wed, Apr 30, 2014 at 1:32 AM, wrote:

    Hi,
    is there are reason to mange pool of running goroutines ?
    use case is network server that receive requests and launch goroutines (
    short lived ) to handle requests.
    does goroutines generate garbage ?

    tanks in advance,

    Djadala



    --
    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.
  • Péter Szilágyi at Apr 30, 2014 at 8:02 pm ⇧
    Hi,

       That scheduling mechanic is perfect for limiting the number of concurrent
    tasks, but a slight problem with it is that the order is not guaranteed
    (i.e. tasks race for execution and thus can introduce random latencies
    because later tasks are scheduled before earlier ones). This may or may not
    be a concern, depends on the tasks. Another solution employed in Iris is
    having a task queue from which the jobs are popped off when workers are
    free [1] (in essence an unbounded channel).

    Cheers,
       Peter

    [1]
    http://godoc.org/github.com/project-iris/iris/pool#example-package--ThreadPool
    On Wed, Apr 30, 2014 at 9:51 PM, 'Thomas Bushnell, BSG' via golang-nuts wrote:

    As others have said, better to spin a new goroutine for each one.

    If you want to limit the total number of concurrent requests, and you were
    using the goroutines for that, I usually use a buffered channel. Stick N
    things on the channel, and goroutines pull one off the channel and hold it
    as a token meaning they're allowed to do work.

    On Wed, Apr 30, 2014 at 1:32 AM, wrote:

    Hi,
    is there are reason to mange pool of running goroutines ?
    use case is network server that receive requests and launch goroutines (
    short lived ) to handle requests.
    does goroutines generate garbage ?

    tanks in advance,

    Djadala



    --
    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.
    --
    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
postedApr 30, '14 at 8:32a
activeApr 30, '14 at 8:02p
posts6
users6
websitegolang.org

6 users in discussion

Dmitry Vyukov: 1 post Benjamin Measures: 1 post Walu Zhang: 1 post Djadala: 1 post Péter Szilágyi: 1 post Thomas Bushnell, BSG: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase