-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tokio integration #267
Comments
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:
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:
Closing this as we won't be integrating with Tokio specifically, but the PR adding |
It would be very nice to be able to use smoltcp with the Tokio ecosystem. For me, the first use case that comes to mind is extremely high-performance servers that use kernel bypass networking, but there are probably many, many others.
The text was updated successfully, but these errors were encountered: