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

@artemave artemave commented Feb 11, 2015

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 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

@artemave artemave commented Feb 11, 2015

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 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.