What would you expect to happen here? A chan that has had one item sent
and then one item received has no items on it, so a receive must wait
until another item is sent.
On Sat, 2021-09-04 at 17:55 -0700, Michael Dwyer wrote:
> I encountered a deadlock when reading from a buffered channel.
> The deadlock occurs when an attempt is made to read from the channel
> twice, without an intermediate write to the channel.
>
> The problematic code is as follows:
>
> func main() {
> myInt := 432
>
> readerChan := make(chan int, 3)
>
> for forI := 0; forI <= 10000; forI++ {
> readerChan <- myInt
> fmt.Printf("%d:", <- readerChan)
> fmt.Printf("%d:", <- readerChan)
> }
>
> close(readerChan)
> }
>
> The first read from variable readerChan succeeds.
> The second read from variable readerChan results in a deadlock.
>
> I have two links to playground.
> The first link is the problematic code.
> The second link is for similar code that has an intervening write to
> the channel.
>
> I understand that a buffered channel allows a queue of results to be
> stored from other Go routines writing to the channel.
> But, the code is attempting multiple read operations.
>
> Looking for a technical explanation to help me better understand this
> particular case.
> Thanks in advance ...
>
>
> The problematic playground link :
> https://play.golang.org/p/veo7phAZzMv
> The working playground link :
> https://play.golang.org/p/qvYZNN9keqN
>
>
> THANX(MKD).
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a7c8565153debfbfae94ca44ffcba6eabec73f9b.camel%40kortschak.io.
