I'd also tend toward passing in a context to the producer rather than
returning a "kill" channel. That way you get correct cancellation when you
begin to string together multiple producers. I'd recommend reading
https://blog.golang.org/pipelines in any case.

https://play.golang.org/p/ftgqSokde1c

On Tue, Jan 22, 2019 at 11:22 AM Josh Humphries <jh...@bluegosling.com>
wrote:

> On Tue, Jan 22, 2019 at 8:33 AM <fabiuz...@gmail.com> wrote:
>
>> Hi, we have the same problem of OP.
>> But, in the Chris's playground there could be an error, indeed if the
>> consumer
>> runs slower of the producer the program ends in a deadlock.
>>
>> To force this behavior just add a time.Sleep() after the foor loop in
>> main.
>> --> https://play.golang.org/p/A3i6TEyGQm_L
>>
>> Am I wrong?
>>
>
> This is wrong because it's not using the select expression in the producer
> correctly. Instead of a default case with unconditional channel write, you
> need the channel write to be one of the cases. Like so:
> https://play.golang.org/p/piR5pyXeV_Y
>
>
>
>>
>> Thanks for the help.
>>
>>
>> Il giorno martedì 21 febbraio 2012 01:51:55 UTC+1, Jan ha scritto:
>>>
>>> hi all, quick question, I have a scenario where the producer should
>>> generate numbers indefinitely, until it is told to stop.
>>>
>>> Most of the channel producer/consumer examples assume that the producer
>>> closes the channels and dies cleanly (on its goroutine).
>>>
>>> When I close the channel on the reader instead, i get a panic. Any
>>> simple ways around it ?
>>>
>>> Pseudo-code:
>>>
>>> func producer() chan int {
>>>   c := make(chan int)
>>>   for {
>>>     // produce number
>>>     c <- some_number
>>>   }
>>> }
>>>
>>> func main() {
>>>   c := producer()
>>>   for some_condition {
>>>     consume(<-c)
>>>   }
>>>   close(c)
>>>   ...
>>> }
>>>
>>> Since I'm going to call this producer zillions of times, I want to make
>>> sure whatever memory/resources it uses is reclaimed and cleanly exited when
>>> c is closed.
>>>
>>> Ideas ?
>>>
>>> many thanks in advance :)
>>> Jan
>>>
>>> --
>> 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.
>>
> --
> 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.
>

-- 
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.

Reply via email to