sync: remove try_recv() from mpsc types

[carllerche]

The mpsc try_recv() functions have an issue where a sent message
happens-before a call to try_recv() but try_recv() returns None.
Fixing this is non-trivial, so the function is removed for 1.0. When the
bug is fixed, the function can be added back.

Closes #2020

[LinusCDE]

Would be nice to have a replacement for this. Trying to migrate to 1.X and this was one of my roadblocks.

I'm using UnboundedReceiver as a means to "listen to events". The data sent is already timestamped, since a accurate time was needed anyways.

(One usecase has me basically polling on this receiver to summarize it's data in a regular interval. The context is async, but since I need to access some shared state I used a 200ms interval to reduce potential mutex locks in case a lot of small data packets arrive.)

I currently don't see a trivial way to drain a Receiver of all new messages without waiting for the next item.

I'll probably use a dirty workaround for the time being and look into a better overall fix using timeout more wholeheartedly.

// Read all available messages at once
- while let Ok(event) = event_receiver.try_recv() {
- // ...
- }
+ let started = std::time::Instant::now();
+ while let Ok(Some(event)) = tokio::time::timeout(Duration::from_millis(50), event_receiver.recv()).await {
+ // Interrupt this loop after at least 100 millis to prevent unlimited looping in edge cases
+ if started.elapsed() > Duration::from_millis(100) {
+     break;
+ }
+ // ...
+ }

This may change my polling interval from 200ms to 349.9ms, but this works for me for the time being.

[Darksonn]

@LinusCDE Is there any reason you aren't using the workaround described in #3350?

[LinusCDE]

@LinusCDE Is there any reason you aren't using the workaround described in #3350?

I didn't know about that solution. This is great! Thanks for making me aware of that!