Re: [go-nuts] context.Context and worker pools

thanks to both for your replies! On Fri, Feb 16, 2018 at 4:43 PM, 'Bryan Mills' via golang-nuts wrote: > Pool the resources, not the workers. > > For example, if your resource is “memory footprint of in-flight requests”, > use a semaphore instead. (There is a

Re: [go-nuts] context.Context and worker pools

Pool the resources, not the workers. For example, if your resource is “memory footprint of in-flight requests”, use a semaphore instead. (There is a “worker pool” example in the package docs.) If your resource is a fixed-size set of connections,

Re: [go-nuts] context.Context and worker pools

I did something like this here: https://github.com/brunoga/workerpool I do not store the context anywhere, I pass it to my Start() method and it passes it down to any place I need it. On Fri, Feb 16, 2018 at 1:05 PM andrey mirtchovski wrote: > While trying to retrofit

[go-nuts] context.Context and worker pools

While trying to retrofit context.Context within a worker-pool-patterned package, where work is sent down a channel to be picked up by number of worker goroutines. I'm running against the mantra of "Do not store Contexts inside a struct type". For example, I want to put a timeout on the amount of