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.