What's the use case for io.async?

[Sze]

@lalinsky

However, when would you actually want to use io.async? If you are fine with the code executing serially, why would you not just call it as a function?

If the program runs in single-threaded blocking mode async is forced to just call the function, however otherwise you still want to run the asynchronous code asyncronously. (not everyone wants to run their program in blocking mode and the code shouldn’t need to be changed to run it in non-blocking mode)

If you always just use function calls (and this code is part of a library) then the user doesn’t have the option to run it asynchronous.

@lalinsky

I’d much prefer if we have io.spawn that explicitly runs the code in some kind of background executor.

io.async allows that, but if there is no possibility to have a background executor, you can still run the code in single threaded blocking mode, which is slower but enables more use cases. Giving more options to the user.

@lalinsky

However, my main question is, what’s one good use case for io.async?

io.async enables implementation agnostic expression of the actual asyncrony and concurrency (via io.asyncConcurrent), allowing users to write the code once and use it with multiple different io implementations.

Asynchrony is not Concurrency

This is a follow up post about async I/O in Zig that talks about these concepts in a more general manner. Hopefully this will clarify some of the ideas behind the new design that I feel were not fully grasped by a lot of people from the previous post.