Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receive() matcher does not work with "non-blocking" channel send #82

Closed
artemave opened this issue Feb 11, 2015 · 3 comments
Closed

Receive() matcher does not work with "non-blocking" channel send #82

artemave opened this issue Feb 11, 2015 · 3 comments

Comments

@artemave
Copy link

Was that wrong to expect the following to work?

        It("works for non-blocking send", func() {
            channel := make(chan bool)

            go func() {
                time.Sleep(100 * time.Millisecond)

                // non-blocking send
                select {
                case channel <- true:
                default:
                }
            }()

            Eventually(channel).Should(Receive())
        })
@onsi
Copy link
Owner

onsi commented Feb 11, 2015

Hi @artemave - your example is not expected to work but the reason is subtle.

The Receive matcher performs a non-blocking read on the channel.
Eventually periodically polls the Receive matcher.

It is very unlikely (in fact, impossible with GOMAXPROCS=1) for your non-blocking send to take place at the same time as the non-blocking read.

Instead you'll need to do something a bit more "traditional" like:

        It("works for non-blocking send", func() {
            channel := make(chan bool)

            go func() {
                time.Sleep(100 * time.Millisecond)

                // non-blocking send
                select {
                case channel <- true:
                default:
                }
            }()

            select {
                case <-channel:
                case <-time.After(time.Second):
                     Fail("timed out waiting to read from channel")
            }
        })

@artemave
Copy link
Author

Yep, that is what I ended up doing.

Perhaps it might be worth mentioning this subtlety in the documentation? Because it certainly looked broken on the surface.

@onsi
Copy link
Owner

onsi commented Feb 11, 2015

yes good point. I'll work on that now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants