pool of goroutines

[dja...@gmail.com]

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

[Walu Zhang]

i think you'd like to open a new goroutine

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

--

---------

Hi, I'm walu

http://weibo.com/walu

http://www.walu.cc

[Benjamin Measures]

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

[Dmitry Vyukov]

On Wed, Apr 30, 2014 at 12:32 PM, <dja...@gmail.com> 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.

[Thomas Bushnell, BSG]

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.

[Péter Szilágyi]

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