Add unit test showing some unexpected behaviour of mpsc::channel

[bikeshedder]

In 'deadpool' I noticed some weird behaviour when calling Receiver::try_recv on a channel which is protected by a semaphore in such a way that the size can't exceed its limit: https://github.com/bikeshedder/deadpool/blob/6daa2e7b5bd06d0b516b83f9da1902848e7812e7/src/lib.rs#L266

I noticed more objects being returned to the pool than the max_size which just didn't make any sense. After some digging I found that try_recv sometimes does not return Ok even if something has already been put into the channel before via try_send.

This behaviour can be reproduced with the following steps:

• Create a semaphore with size 1
• Create a channel and fill it with one message
• Spawn two tasks
• One of the tasks manages to acquire the permit, receive the message from the channel and send it back. Afterwards the permit is dropped.
• Now the other task tries to do the same and fails during the try_recv call.

I have no idea how to fix that but please find that test case attached.

As using channel just with try_send and try_lock is a bit wasteful in my case anyways I just found crossbeam_queue which supports concurrent push/pop without any locking.

I'm afraid I might have actually introduced that bug myself when adding Receiver::try_recv.

[carllerche]

You are not awaiting the permit. Adding an .await makes the test pass.

[carllerche]

Looks like the bug was in the test. I'm going to close this as the test passes once it is fixed 👍

I think if you didn't explicitly drop the permit, you would have gotten a must_use warning?

[bikeshedder]

I have just rebased the branch to the current master, fixed the error in the test and changed the scheduler to threaded_scheduler and increased the count of permits, workers and cycles. As that error is highly timing dependant it's not guaranteed that the error will show up on the first run. When increasing the CYCLES to 100_000 the error will almost always show up.

I totally messed that test up while trying to come up with a test that contains as little noise as possible. That's the smallest test I was able to come up with. I bet there is an even simpler way to reproduce that which I'm currently unaware of.