Comment by throwawaymaths
Comment by throwawaymaths 14 hours ago
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).
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.