|
|
Log in / Subscribe / Register

One and a half colors

One and a half colors

Posted Dec 3, 2025 9:58 UTC (Wed) by muase (subscriber, #178466)
In reply to: One and a half colors by khim
Parent article: Zig's new plan for asynchronous programs

> That's because you couldn't simply pass any random async function into any random executor… the functions that do actual work have to match the executor or else the whole things falls apart — and these functions are invisible in Rust's async fn signature.

Could you elaborate what you mean with that? Because I have heavily used async within the embedded world, and I struggle to understand your point.

Async has two relevant API components: futures and wakers. As long as I implement a correct future, and use the provided opaque waker to wake the executor, I don’t see how my implementation has to match the executor?

And in my experience that works pretty well IRL; I have quite a few projects where I switched from my own executor to embassy, and two projects where I did vice versa, and I’ve never encountered any problems so far…


to post comments

One and a half colors

Posted Dec 3, 2025 11:22 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

> Async has two relevant API components: futures and wakers.

Nope. It has three components, or, more precisely, two and half: futures+wakers and executors. These have to match or the whole thing goes down in flames.

> As long as I implement a correct future, and use the provided opaque waker to wake the executor, I don’t see how my implementation has to match the executor?

Because your waker has to match the executor. And said waker, as you have said, is opaque and is not present in the function signature so compiler couldn't verify that they match.

> I have quite a few projects where I switched from my own executor to embassy, and two projects where I did vice versa, and I’ve never encountered any problems so far…

And how many of these have both of these executors running, simultaneously? Note that it's not even a purely theoretical interest. There are tokio and tokio_uring — and they are incompatible (certain things in tokio make it impossible to use in one project). You may want, e.g., use tokio for network-related tasks and tokio_uring for disk access (where tokio is lacking). But if you try to do that you would quickly find out that mixing different futures (and thus different wakers) can easily lead to trouble.

One and a half colors

Posted Dec 4, 2025 21:40 UTC (Thu) by ofranja (subscriber, #11084) [Link]

> And how many of these have both of these executors running, simultaneously?

You can have multiple runtimes side-by-side in Rust, unless there is a specific limitation on the implementation of your runtime that prevents it. Nevertheless, it would be an implementation issue and not a language issue.

If you want an example, send this request to the LLM of your preference:

"Please write a simple example of a Rust program using async-std and tokio simultaneously in the same program."

> But if you try to do that you would quickly find out that mixing different futures (and thus different wakers) can easily lead to trouble.

You might not be able to use certain functions from a runtime's library in another runtime if they are implemented by the runtime itself - ie: what you call is a function that signals an action to the runtime and the function itself does not "execute" anything, and just waits for the action to complete.

In any case, this is easily solvable by communicating between different runtime contexts using channels and matching the library function calls to the particular runtime.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds