Request for try_receive() or some variant of non-blocking receive for EventQueue

[RobDavenport]

Awesome create! I'm really impressed with the ergonomics and flexibility of this so far!

It would be nice to have access to a non-blocking receive function inside of EventQueue.

Reasons

• Working within a game-loop with specific times to handle events.
• Not wanting to deal with multiple threads, inter-thread communication with channels etc.
• (Maybe?) faster performance than the current solution listed below due to unnecessary creation of Duration & compares against times.

Current solution: Calling receive_timeout with zero duration, such as: events.receive_timeout(Duration::from_nanos(0))

I considered making a PR for this myself (and probably will if it doesn't get added by anyone else), unless it's deemed unnecessary or pointless compared to the current solution. The code looked a little more involved than I thought though!

[lemunozm]

Thanks @RobDavenport!! I am glad that you like message-io :D

I' am not sure about the delay events.receive_timeout(Duration::from_nanos(0)) generates, I think that it is minimal, but it's true that you stop the process into an OS select and maybe sometimes it produces some delay by the OS to recover the process.

Anyway, I like the idea of a PR! I think that something like events.try_receive() (which would return an option) is simpler and more readable for your use case than the current solution.

The crossbeam channel has already a try_recv function, so I think that the solution would consist into call try_recv to the three internal receivers that EventQueue has.

If you want to contribute, it would be great! Thanks!