Primary channel instance which isn’t working – Technical Dialogue

func foremost() {
    c := make(chan int, 1)
    go ship(c)
    go obtain(c)
}

// ship channel
func ship(c chan<- int) {
    for i := 0; i < 10; i++ {
        c <- i
    }
    //shut(c)               //  dont should do it , this isn't logical.
}

// obtain channel
func obtain(c <-chan int) {
    for v := vary c {                                                                              // that is an limitless loop that can maintain operating as soon as the channel may have content material.
        fmt.Println("Obtained from the channel:", v)                    this loop will cease solely in case the channel will get closed. 
    }
}

what’s the idea right here that i’m lacking , why is it not exhibiting any output ?
when i add the “shut(c)” it’s working, however i don’t wish to shut any channels – need them to be open
for additional use.

thanks upfront. @)
#channels #go channels #plz add hash tags – i believe it’ll assist round right here.

Hello @edgarlip,

After spawning the 2 goroutines, foremost has nothing extra to do and exits. When it exits, the method exits and all goroutines cease forcefully. obtain() has no likelihood to print something.

Listed here are just a few methods to keep away from this:

1. The short repair: name obtain() immediately (that’s, take away the go key phrase), in order that it runs in the principle stream.
2. For extra complicated situations: add all goroutines to a WaitGroup and have foremost watch for the group to finish.
3. The soiled hack: on the finish of foremost, add a name that blocks perpetually, like choose{}. Exit the app with Ctrl-C.

Hello @christophberger
thanks for the short replay !
primarily based on you remark i’ve got here up with this code :

func foremost() {
	c := make(chan int, 12)
	var wg sync.WaitGroup
	wg.Add(2)
	go ship(c, &wg)
	go obtain(c, &wg)
	wg.Wait()
}

// ship channel
func ship(c chan int, wg *sync.WaitGroup) {
	for i := 0; i < 10; i++ {
		fmt.Println("inserting stuff to channel c ", i)
		c <- i
	}
	fmt.Println("ship func completed")
	shut(c)
	wg.Achieved()
}

// obtain channel
func obtain(c chan int, wg *sync.WaitGroup) {
	for v := vary c {
		fmt.Println("the worth obtained from the channel:", v)
	}
	fmt.Println("obtain func completed")
	wg.Achieved()
}

however nonetheless as u can see within the ship operate i see that the shut() is a should ?

Sure, it is advisable shut the channel as a result of the vary loop reads from the channel till it’s closed.

In different phrases, closing a channel is like sending a sign to the vary operator in order that it is aware of that no extra information will probably be coming by way of the channel.

thanks @christophberger
i understood your reply , and it was very useful to for clearing the uncertainty.
will simply add right here the ultimate code that i believe that give the idea of ready endlessly to some factor, with the
“choose” performance that you simply talked about = )

func foremost() {
    even := make(chan int)
    odd := make(chan int)
    stop := make(chan bool)
    var wg sync.WaitGroup
    wg.Add(2)

    go send2(even, odd, stop, &wg)
    go receive2(even, odd, stop, &wg)

    wg.Wait()
    fmt.Println("*** performed *** ")
}

// ship channel
func send2(even chan int, odd chan int, stop chan bool, wg *sync.WaitGroup) {
    for i := 0; i < 10; i++ {
        if ipercent2 == 0 {
            even <- i
        } else {
            odd <- i
        }
    }
    stop <- true
    wg.Achieved()
}

// obtain channel
func receive2(even, odd chan int, stop chan bool, wg *sync.WaitGroup) {
    for {
        choose {
        case v := <-even:
            fmt.Println("the worth obtained from the even channel:", v)
        case v := <-odd:
            fmt.Println("the worth obtained from the odd channel:", v)
        case <-quit:
            fmt.Println("obtained worth on channel stop !")
            wg.Achieved()
            return
        }
    }
}

BR,