2018-05-05 11:11 GMT+03:00 Andriy Pylypenko :
> I'll note in passing that pools of goroutines are not the best idiom
>> for Go. Starting new goroutines is cheap. It's generally simpler to
>> spin up goroutines as needed then to keep a pool of goroutines around.
>> In this model use a separate se
2018-05-04 21:31 GMT+03:00 Ian Lance Taylor :
> On Fri, May 4, 2018 at 11:10 AM, Andriy Pylypenko
> wrote:
> >
> > In fact I have that guarantee because the supplier thread is a single
> > goroutine and it guarantees that there would be no items on the work_ch
> > after the idle state is requeste
On Fri, May 4, 2018 at 11:10 AM, Andriy Pylypenko wrote:
> 2018-05-04 19:32 GMT+03:00 Ian Lance Taylor :
>>
>> On Fri, May 4, 2018 at 2:00 AM, wrote:
>> >
>> > And I want to modify the worker thread like this:
>> >
>> > for {
>> > select {
>> > case wi := <- work_ch:
>> > self.do
2018-05-04 19:32 GMT+03:00 Ian Lance Taylor :
> On Fri, May 4, 2018 at 2:00 AM, wrote:
> >
> > And I want to modify the worker thread like this:
> >
> > for {
> > select {
> > case wi := <- work_ch:
> > self.do_the_work(wi)
> > case <-self.idle_request:
> > self.idle_
2018-05-04 18:24 GMT+03:00 Bruno Albuquerque :
> Here is an example that came up in the list that might help you:
> https://play.golang.org/p/I8MS0DFgZ2
>
Thank you! This is exactly the code I looked for.
However I should say this approach is not very much elegant because the
select statement ra
On Fri, May 4, 2018 at 2:00 AM, wrote:
>
> And I want to modify the worker thread like this:
>
> for {
> select {
> case wi := <- work_ch:
> self.do_the_work(wi)
> case <-self.idle_request:
> self.idle_response <- true
> }
> }
>
> However this last snippet of code
Here is an example that came up in the list that might help you:
https://play.golang.org/p/I8MS0DFgZ2
That being said, It looks like you are over engineering. If I really
understand what you want to accomplish, wouldn't this help?
https://github.com/brunoga/workerpool
You can call Stop()/Start()
