Cool stuff!
On Wed, Jul 27, 2022 at 3:46 PM Brian Candler wrote:
> I see. There's a concrete benefit in using the waitgroup though: it would
> have shown you the second write blocking.
> https://go.dev/play/p/WNHRkkUUZUt
>
> On Wednesday, 27 July 2022 at 10:43:01 UTC+1 aravind...@gmail.com wrote
I see. There's a concrete benefit in using the waitgroup though: it would
have shown you the second write blocking.
https://go.dev/play/p/WNHRkkUUZUt
On Wednesday, 27 July 2022 at 10:43:01 UTC+1 aravind...@gmail.com wrote:
> Thanks Brian, Got it.
> "A send cannot take place until the reader is r
Thanks Brian, Got it.
"A send cannot take place until the reader is ready to receive." . So an
unbuffered channel does not have the same behaviour as a buffered channel
of size 1, fair.
I understand part about the waitGroup, I copy pasted code used to tutor the
newcomers to programming itself.
On
BTW, using time.Sleep() to keep goroutines running is poor practice.
What I suggest is using a sync.WaitGroup. Call wg.Add(1) for each
goroutine you start; call wg.Done() when each goroutine ends; and call
wg.Wait() to wait for them.
https://go.dev/play/p/INl7BxG0ZSU
On Wednesday, 27 July 2022
Unless a channel is buffered, it is synchronous. A send cannot take place
until the reader is ready to receive.
You can make it buffered using
numCh = make(chan int, 1)
go write()
go read()
Or you can have two calls to read():
numCh = make(chan int)
go write()
go read()
