[throwawaymaths]

is it not the case that in zig, the execution happens in a_future.await?

I presume that:

io.async 1 stores in io "hey please work on this"

io.async 2 stores in io "hey also please work on this"

in the case where io is evented with some "provided event loop":

await #1 runs through both 1 and 2 interleavedly, and if 2 finishes before 1, it puts a pin on it, and then returns a_result when 1 is completed.

await #2 "no-executions" if 1 finished after 2, but if there is still work to be done for 2, then it keeps going until the results for 2 are all in.

There's no "task that's running somewere mysteriously" unless you pick threaded io, in which case, yeah, io.async actually kicks shit off, and if the cpu takes a big fat nap on the calling thread between the asyncs and the awaits, progress might have been made (which wouldn't be the case if you were evented).

[amluto]

There’s a material distinction. In Zig (by my reading of the article — I haven’t tried it), as you say:

> await #1 runs through both 1 and 2 interleavedly, and if 2 finishes before 1, it puts a pin on it, and then returns a_result when 1 is completed.

In Rust or Python, awaiting a future runs that future and possibly other tasks, but it does not run other non-task futures. The second async operation would be a non-task future and would not make progress as a result of awaiting the first future.

It looks like Zig’s io.async sometimes creates what those other languages call a task.

[throwawaymaths]

i am not familiar with rust and i gave up on python async years ago so i have no frame of reference here. but im really not sure why theres a need to distinguish between tasks and non tasks?

importantly in zig the execution isnt just limited to #1 and #2. if the caller of this function initiated a #3 before all of this it could also get run stuffed in that .await, for example.