4 ms·

If you think I suggest to abstract sync code (like some old version of rust was seamingly doing), you are missing my point. There is just no need for async I/O

by fooyc 10y ago

If you think I suggest to abstract sync code (like some old version of rust was seamingly doing), you are missing my point. There is just no need for async I/O. Just bring "zero-cost" multi tasking / coroutines to your language, and you don't need async anymore.

Rusky 10y ago
You can't really do IO in coroutines without async IO in the implementation, and (depending on your baseline) you can't make them zero-cost without something like async/await.
- fooyc 10y ago
  IIRC, a read() in Go is just a plain synchronous read() under the hood. They just let an other coroutines execute during the syscall.
  - Rusky 10y ago
    > They just let an other coroutines execute during the syscall. They do this by using async IO under the hood (for network sockets at least- convincing disk-based read() calls to be async is much tricker and Go doesn't do it).
- fooyc 10y ago
  Can you explain why ?
  - lucozade 10y ago
    Because synchronous IO will block the OS thread. If you're multiplexing a bunch of green threads on that OS thread, they'll all stall. That's why Go, for example, does use async IO. But it makes the use of it look like sync IO for simplicity. In the runtime, however, it is doing all the async event management so that you don't have to. From a programmer POV this is a good thing, but it comes at the price of a runtime that has to exist. Something that Rust eschews.
  - Rusky 10y ago
    Sibling comment by lucozade is good. To be more specific, it's because OS-level threads are the only way the kernel gives applications to run any code at all. When an OS-level thread makes a syscall, it ceases to run any application code until that syscall completes- it's just an ordinary function call that also switches to kernel mode. The OS kernel itself provides both blocking and asynchronous syscalls. So if your OS-level thread is switching between several coroutines, and one of them makes a synchronous read() syscall, the whole OS-level thread blocks and can't run any other coroutines until the read completes. If it instead makes an asynchronous syscall, the kernel returns immediately and the OS-level thread can switch to another coroutine while the first one waits.

by fooyc 10y ago

Rusky 10y ago

You can't really do IO in coroutines without async IO in the implementation, and (depending on your baseline) you can't make them zero-cost without something like async/await.

fooyc 10y ago
IIRC, a read() in Go is just a plain synchronous read() under the hood. They just let an other coroutines execute during the syscall.
- Rusky 10y ago
  > They just let an other coroutines execute during the syscall. They do this by using async IO under the hood (for network sockets at least- convincing disk-based read() calls to be async is much tricker and Go doesn't do it).
fooyc 10y ago
Can you explain why ?
- lucozade 10y ago
  Because synchronous IO will block the OS thread. If you're multiplexing a bunch of green threads on that OS thread, they'll all stall. That's why Go, for example, does use async IO. But it makes the use of it look like sync IO for simplicity. In the runtime, however, it is doing all the async event management so that you don't have to. From a programmer POV this is a good thing, but it comes at the price of a runtime that has to exist. Something that Rust eschews.
- Rusky 10y ago
  Sibling comment by lucozade is good. To be more specific, it's because OS-level threads are the only way the kernel gives applications to run any code at all. When an OS-level thread makes a syscall, it ceases to run any application code until that syscall completes- it's just an ordinary function call that also switches to kernel mode. The OS kernel itself provides both blocking and asynchronous syscalls. So if your OS-level thread is switching between several coroutines, and one of them makes a synchronous read() syscall, the whole OS-level thread blocks and can't run any other coroutines until the read completes. If it instead makes an asynchronous syscall, the kernel returns immediately and the OS-level thread can switch to another coroutine while the first one waits.