Future types are not really meant to be .awaited more than once. Rust does technically allow it, but it makes for a counterintuitive and abnormal API. Additionally, (&mut commander).await looks worse IMO than something like commander.next().await or commander.recv().await.

I suggest to either implement Stream which has the exact semantics that you want from the current Future implementation, or to provide an async fn recv(&mut self) instead.

Describe the bug
Unable to use .poll_next() on a Channel<Option>.

To Reproduce
Steps to reproduce the behavior:

1. Add crate whisk, version 0.11.0, with features futures_core
2. Add crate tokio, version 1.28.2, features: rt-multi-thread, macros
3. Create channel with Channel::new()
4. clone channel and give clone to tokio async task (two runtimes?, am not using async::main)
5. no method 'poll_next' found for struct 'Channel<Option>' (the original channel pointer)

Expected behavior
the method 'poll_next' returns an option within a for loop:
Some(VideoUpdate)
or None for channel has been cleared

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
  Linux 5.15.0-71-generic #78~20.04.1-Ubuntu SMP Wed Apr 19 11:26:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Additional context
I am pretty new to programming but I imagine there could be some conflicts between two async runtimes pasts and tokio,
I aim for my crate to be easily made nostd, but also trying to balance that with readability to a client who does not understand
the details, so using tokio's task and writing it like a thread spawn with task::spawn is very nice, and I would love to be able to
understand more about how I would create a similar interface using only pasts as nostd is the end goal.

The future contract is such that:

• When poll is called multiple times, the wakers are not guaranteed to be the same.
• Waking a waker from an old call to poll may not have any effect.
• If you return Poll::Ready from poll, the waker you have is basically completely worthless.
• If you return Poll::Pending from poll, but have not woken or cloned the waker given to you in that poll call's cx.waker(), you may wait forever.

This crate makes many assumptions about how the caller gives its futures wakers that do not hold under Future's contract. This means that it's possible that perfectly valid executor implementations would leave this crate's futures hanging forever. What you need to do is update the stored waker each time poll is called. Be careful about data races though, storing a new waker is not atomic so you'll have to use additional atomics to synchronize it.

• Remove Weak::try_recv() #23
• Wait for pasts 1.0.0, or find a way to make backwards compatible (old pasts versions depending on new - but not exactly?)
• Make some functions const? Like Channel::new() and Weak::new() ¹ (could be put off)
• Do better benchmarks #21 (could be post 1.0.0)
• Attempt lockless waker #18 (could be post 1.0.0)
• #27 (could be post 1.0.0)
• #31

commander.start().await;
for message in &mut commander {
}

Might be able to become:

for message in commander.start().await {
}

Associated data on Queue and Channel; Can any !Sized (dyn) be constructed or is it pointless to specify ?Sized?

https://docs.rs/whisk/latest/whisk/fn.channel.html

If it's possible to avoid spinlocks for the waker synchronization, it would probably make this crate faster.

Currently whisk is limited to a single element in the mpmc queue. This queue is implemented as a simple Option, but could use an implementation of a pre-allocated list with a maximum capacity set via a const generic.

For convenience, but should also be more efficient than upgrading and calling the respective methods.

Reason:

It's virtually impossible to guarantee that it won't wait indefinitely.

• Weak is upgraded internally for duration of receive
• Channel (original) is dropped
• Waiting on channel with no senders

Weak senders on the other hand:

• Weak is upgraded internally for duration of send
• Channel (original) is dropped
• Send to channel with no receiver(s)
• Send complete

If there's a way to remove them without impacting performance, that would make it a bit easier to use the API

This shouldn't add much code, and could be useful in some situations.

The public api Message type doesn't do much and could be replaced with impl Future<Output = ()> + Send + Sync + Unpin

API should use oneshot-style communication for messages, but not for commands.

Allocation Reduction

Should be able to create a custom struct that contains a whisk::Channel and constructs as Arc<Self> containing the channel (but not within another Arc).

#[derive(Clone)]
struct MyChannelWrapper<T, U> {
   data: T,
   channel: whisk::Channel<U>,
}

impl<T, U> MyChannelWrapper<T, U> {
    fn new() -> Arc<Self> { ... }
}

I worked around having to have it, but it would just be much simpler.