On Fri, May 4, 2018 at 11:10 AM, Andriy Pylypenko <bambys...@gmail.com> wrote:
> 2018-05-04 19:32 GMT+03:00 Ian Lance Taylor <i...@golang.org>:
>>
>> On Fri, May 4, 2018 at 2:00 AM, <bambys...@gmail.com> 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 does not work because the cases within
>> > the
>> > select statement are randomly chosen when both channels are ready so I
>> > have
>> > no guarantee that the first case is executed first.
>>
>> You also have no guarantee that a request won't arrive on work_ch a
>> nanosecond after the worker is told to go idle, but presumably that is
>> not a problem.
>
>
> 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.
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.
Ian
--
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.
