Values received out-of-order in a single-threaded async single-producer single-consumer scenario (involving tokio::select). about flume

[rzheka]

No problem, will open a PR.

[rzheka]

After some debugging, I see that the following path in Shared<T>::send() is taken occasionally:

flume/src/lib.rs

Line 480 in 64657a1

chan.queue.push_front(m);

Was the intention really to push_front() here (as opposed to push_back())?

[Restioson]

Worth looking into - note that it uses front again at L468

[zesterer]

@rzheka Did you have the time to fork, switch to push_back, and confirm whether this continues to happen or not?

[rzheka]

With push_back this doesn't happen, my test works fine (I didn't prepare any PR yet, just investigated and played with it on local repo).
The question, though, is whether this push_front was intentional, or it's just a typo?

[zesterer]

The question, though, is whether this push_front was intentional, or it's just a typo?

I suspect that it was a typo. The async code paths are not so well tested, and I believe one (and perhaps both) of these cases are not hit without async code being enabled, and the tests probably don't check for ordering in the cases where they are.

Is there any chance you could open a PR with this change?