2018-05-04 21:31 GMT+03:00 Ian Lance Taylor <i...@golang.org>: > On Fri, May 4, 2018 at 11:10 AM, Andriy Pylypenko <bambys...@gmail.com> > 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 requested and before the worker responded. Also > the > > worker is never requested to stop, it is only requested to report that it > > has completed all the work and it is now idle. > > In that case, drain the work channel after receiving the idle request > and before sending the idle response. >
Thank you for good hint, it's currently the best solution for my task. However the resulting code becomes slightly overengineered comparing to the select()/poll() approach. 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 semaphore, such as a buffered channel, to > limit the number of goroutines doing work concurrently. > It's a good approach when there is no need to maintain other resources per goroutine such as DB connection which you don't want to reconnect for every work item. In that case one is forced to maintain a pool of those resources which may become unnecessary complicated. -- Andriy -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
