Are thread pools pointless in Go?

[Travis Reeder]

Coming from Java, we used thread pools a lot (usually via java.util.concurrent).  Is there a concept of go-routine pools or does Go just take care of that kind of thing behind the scenes?  In other words, is it generally fine to just keep firing off tons of go-routines and not worry about it?

[Devon H. O'Dell]

2011/9/16 Travis Reeder <tre...@gmail.com>:

Goroutines are pooled over $GOMAXPROCS system threads by the runtime
(for the native compiler chain). Gccgo still currently has a 1:1
goroutine:thread ratio, but this is intended to change Sometime
Soon(tm).

Heavy thread pool use in Java happens because it is very expensive to
create Java threads, so we use FutureTasks instead and pool those. It
is comparatively very inexpensive to create goroutines.

For these reasons, I would posit that thread pooling is not something
you should worry about.

--dho

[roger peppe]

i once benchmarked some code (time.After) with and without
thread pooling, and i think i remember it was marginally
faster without. it's certainly simpler, and i think that creating
a goroutine has the potential to be faster without a pool
(even if it isn't already) because no inter-processor locking needs to
take place.

[André Moraes]

Usually you will create pool of objects instead of pool of threads.

See the Leaky Buffer sample:

http://golang.org/doc/effective_go.html#leaky_buffer

Here you define a pool of buffers, so when you need a new buffer to
store bytes you just request one from the channel, and when you finish
using it just put back on the channel.

--
André Moraes
http://andredevchannel.blogspot.com/