Sure. I am not personally invested in Tokio so I will not work on it myself.

This is probably a good idea, but it's strange that high-level abstractions like futures will be in such a low-level crate.

I think futures are pretty low level, it's just another way to represent control flow. In general, microcontroller firmware often greatly benefits from using async/await-like control flow rather than threads; there are many coroutine replacements (not really implementations) for C specifically for this task.

I agree with you.

Do you still working on a Tokio integration? Do you have already a test example?

very interested in tokio integration as well. do you need help?

Sure, would be helpful to have even a proof of concept.

I'd love to see async/await support in smoltcp too!

From some experiments I've done (#382), I believe the best approach is to:

• Add support in smoltcp to associate Wakers to sockets.
• Leave everything else to external higher-level crates.

The higher-level crates would implement wrappers for the smoltcp types that implement the desird async traits (AsyncRead, AsyncWrite, Stream for UDP packets..?).

I believe this is the best way to go, because:

• It is not clear which traits should smoltcp implement:
  • The std ecosystem has multiple competing incompatible traits, mainly tokio and futures.
  • The no_std ecosystem hasn't converged on any standard io traits yet. The tokio and futures traits aren't no_std compatible.
• There are non-trivial tradeoffs when implementing async support: how are sockets allocated, is there a single global tcp/ip stack or multiple, how are lifetimes handled.

Closing this as we won't be integrating with Tokio specifically, but the PR adding Waker support is coming very soon! :)