5 ms·

when set to .blocking > The function is no longer async, and in fact both keywords basically become no-ops That sounds crazy to me, if I use a keyword I expec

by howeyc 6y ago

when set to .blocking > The function is no longer async, and in fact both keywords basically become no-ops That sounds crazy to me, if I use a keyword I expect it to behave the same everywhere I use it. I hope I misunderstood, and that setting come kind of global const can't "disable" async for one library, but still have it enabled when used somewhere else. I would have to keep track of all these various consts to know my app is/isn't actually doing async tasks, even though I've explicitly used the keyword.

kristoff_it 6y ago
It's not a switch for libraries, it's a global project-wide switch. It enables or disables evented I/O for your whole application. Libraries can read that setting and specialize at compile-time appropriately.
- Matthias247 6y ago
  What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. Similar questions might arise around cancellation and timeouts, which are different to perform in an async/evented environment than a synchronous one. In most other worlds the problem is "solved" by declaring a subsystem of the application as async. And only that subsystem is running one or more eventloops. That obviously introduces a different set of issues, but it isolates parts of a program against others. I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used.
  - kristoff_it 6y ago
    > What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. In that case you would add in such library a line like this: if (!std.io.is_async) @compileError("LIB doesn't support blocking mode"); > I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used. That's an open question. In general Zig is more like C than C++ also when it comes to expectations from libraries. We'll see where this will get us.
    - Matthias247 6y ago
      > In that case you would add in such library a line like this: That's certainly an approach to make sure libraries run in the correct environment. But it still doesn't seem to enable use-cases where you run an eventloop on some threads and blocking IO (or just blocking on the eventloop) on other threads, which are often found in bigger programs that are made up of a lot of heterogenous libraries. One could say "you might not need that - just run everything async". But since we are talking about a system programming language where libraries might be exported and used in different projects I'm not sure if that lack of flexbility won't hurt long term.
      - kristoff_it 6y ago
        I think I understand what you're saying. In this introduction I just wanted to give a feeling to people about the biggest building blocks so I didn't have the opportunity of diving into the small details (the article is already fairly long as is). Zig doesn't take shortcuts when it comes to give people control over the machine so what you describe is expected to be possible. The async part of the language is still being worked on (Zig is at v0.6.0 as I write) and the top level API will be reworked if it turns out to be problematic (that's the superpower of being at a version < 1.0).
yellowapple 6y ago
Yeah, per the docs¹ the article doesn't seem to be accurate in that part; none of the doc's examples mention anything about setting something to .blocking v. .evented. The keywords might not actually achieve meaningful concurrency due to implementation details (i.e. a coroutine stuck on a blocking operation, which might be what that particular global variable controls), but they definitely ain't no-ops from what I understand. ---- ¹: https://ziglang.org/documentation/master/#Async-Functions https://ziglang.org/documentation/master/#Async-Functions
- kristoff_it 6y ago
  The docs are about the mechanics of how async frames work with examples of how the control flow jumps based on manual scheduling. The top level constant interacts with the standard library to instantiate an event loop and add non-blocking flags to file descriptors etc. Try the code out, use strace to see the syscalls being made and you will confirm that my article is accurate.
  - AndyKelley 6y ago
    You can also watch the linked video which demos the strace. https://youtu.be/zeLToGnjIUM?t=546 https://youtu.be/zeLToGnjIUM?t=546 (9:06 to 15:24)
  - 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.
lalaithion 6y ago
Setting that global const is the same as choosing between various top-level future executors. It can only be set once in a project, and it's morally equivalent to changing `asyncio.run()` to some other function in the python example. It just allows library writers to write async functions and have the end user choose which async impl to use.

by howeyc 6y ago

kristoff_it 6y ago

It's not a switch for libraries, it's a global project-wide switch. It enables or disables evented I/O for your whole application. Libraries can read that setting and specialize at compile-time appropriately.

Matthias247 6y ago
What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. Similar questions might arise around cancellation and timeouts, which are different to perform in an async/evented environment than a synchronous one. In most other worlds the problem is "solved" by declaring a subsystem of the application as async. And only that subsystem is running one or more eventloops. That obviously introduces a different set of issues, but it isolates parts of a program against others. I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used.
- kristoff_it 6y ago
  > What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. In that case you would add in such library a line like this: if (!std.io.is_async) @compileError("LIB doesn't support blocking mode"); > I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used. That's an open question. In general Zig is more like C than C++ also when it comes to expectations from libraries. We'll see where this will get us.
  - Matthias247 6y ago
    > In that case you would add in such library a line like this: That's certainly an approach to make sure libraries run in the correct environment. But it still doesn't seem to enable use-cases where you run an eventloop on some threads and blocking IO (or just blocking on the eventloop) on other threads, which are often found in bigger programs that are made up of a lot of heterogenous libraries. One could say "you might not need that - just run everything async". But since we are talking about a system programming language where libraries might be exported and used in different projects I'm not sure if that lack of flexbility won't hurt long term.
    - kristoff_it 6y ago
      I think I understand what you're saying. In this introduction I just wanted to give a feeling to people about the biggest building blocks so I didn't have the opportunity of diving into the small details (the article is already fairly long as is). Zig doesn't take shortcuts when it comes to give people control over the machine so what you describe is expected to be possible. The async part of the language is still being worked on (Zig is at v0.6.0 as I write) and the top level API will be reworked if it turns out to be problematic (that's the superpower of being at a version < 1.0).

yellowapple 6y ago

Yeah, per the docs¹ the article doesn't seem to be accurate in that part; none of the doc's examples mention anything about setting something to .blocking v. .evented. The keywords might not actually achieve meaningful concurrency due to implementation details (i.e. a coroutine stuck on a blocking operation, which might be what that particular global variable controls), but they definitely ain't no-ops from what I understand. ---- ¹: https://ziglang.org/documentation/master/#Async-Functions https://ziglang.org/documentation/master/#Async-Functions

kristoff_it 6y ago
The docs are about the mechanics of how async frames work with examples of how the control flow jumps based on manual scheduling. The top level constant interacts with the standard library to instantiate an event loop and add non-blocking flags to file descriptors etc. Try the code out, use strace to see the syscalls being made and you will confirm that my article is accurate.
- AndyKelley 6y ago
  You can also watch the linked video which demos the strace. https://youtu.be/zeLToGnjIUM?t=546 https://youtu.be/zeLToGnjIUM?t=546 (9:06 to 15:24)
- 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.

lalaithion 6y ago

Setting that global const is the same as choosing between various top-level future executors. It can only be set once in a project, and it's morally equivalent to changing `asyncio.run()` to some other function in the python example. It just allows library writers to write async functions and have the end user choose which async impl to use.