3 ms·

Oh, I see. So blocking still executes asynchronously (perhaps spawning a thread or something, so the program can continue on), but setting eventing will use an

by howeyc 6y ago

Oh, I see. So blocking still executes asynchronously (perhaps spawning a thread or something, so the program can continue on), but setting eventing will use an event-based mechanism?

dathinab 6y ago
> (perhaps spawning a thread or something, so the program can continue on) No as far as I understand blocking just blocks. Which is the problematic part. > The function is no longer async, and in fact both keywords basically become no-ops, but the point is that you can express concurrency even if you’re not able to take advantage of it. (Emphasis done by me) For many cases this is fine as "async" could just have completed one the first poll which we could just have done before the first yield. But the problem is if you try to do something like calling two functions async which needs synchronization between them to complete. Something you generally should really avoid. But sometimes this is the only sane way to do certain things in complex systems. (But then it might make sense to simplify such a system or split it apart). So I would say for many use-cases including all normal web-servers Zig's solutions is not just good but preferable. But to do some things it's bad. Through it's just a question to add some escape hatches for the view cases where it matters or so. Anyway spawning a thread on every `async` call if `.blocking` is used would be really bad.
- AndyKelley 6y ago
  One could do the synchronization thing with zig's async await, it would just cause the code to become a compile error in blocking I/O mode. The code author would then have the option to document that function / library / application as not supporting blocking I/O mode, or explicitly put an `if (std.io.io_mode == .blocking)` check there and provide a blocking implementation.

3 ms·

Oh, I see. So blocking still executes asynchronously (perhaps spawning a thread or something, so the program can continue on), but setting eventing will use an

by howeyc 6y ago

Oh, I see. So blocking still executes asynchronously (perhaps spawning a thread or something, so the program can continue on), but setting eventing will use an event-based mechanism?

dathinab 6y ago
> (perhaps spawning a thread or something, so the program can continue on) No as far as I understand blocking just blocks. Which is the problematic part. > The function is no longer async, and in fact both keywords basically become no-ops, but the point is that you can express concurrency even if you’re not able to take advantage of it. (Emphasis done by me) For many cases this is fine as "async" could just have completed one the first poll which we could just have done before the first yield. But the problem is if you try to do something like calling two functions async which needs synchronization between them to complete. Something you generally should really avoid. But sometimes this is the only sane way to do certain things in complex systems. (But then it might make sense to simplify such a system or split it apart). So I would say for many use-cases including all normal web-servers Zig's solutions is not just good but preferable. But to do some things it's bad. Through it's just a question to add some escape hatches for the view cases where it matters or so. Anyway spawning a thread on every `async` call if `.blocking` is used would be really bad.
- AndyKelley 6y ago
  One could do the synchronization thing with zig's async await, it would just cause the code to become a compile error in blocking I/O mode. The code author would then have the option to document that function / library / application as not supporting blocking I/O mode, or explicitly put an `if (std.io.io_mode == .blocking)` check there and provide a blocking implementation.