3 ms·

I don’t really get your point. You cannot, (should not), do blocking IO in async in any language. The language provides libraries to do non blocking IO. What

I don’t really get your point. You cannot, (should not), do blocking IO in async in any language. The language provides libraries to do non blocking IO. What is unclear about that? Multi threading has nothing to do with async, except as a way to run certain things in an executor thread to avoid blocking. Also I don’t really know what you mean by async IO…. even in the languages you reference I would guess IO operations are all run in a single thread.

bad_user 3y ago
> You cannot, (should not), do blocking IO in async in any language. On platforms with 1:1 scheduling, of course you can. Blocking I/O executed on another thread, with a callback to execute when done, becomes async I/O (from the user's PoV). Ofc, when we talk about async I/O, we also refer to the kernel APIs being used, such as select/poll/epoll/io_uring. Say, working with Epoll is usually done via a single-threaded "event loop", but that only listens for the operations possible for an open file/socket. The read/write operations are still potentially blocking, so for efficiency you need multiple threads. The dirty secret is that async I/O, as implemented by Linux, isn't actually fully async.
- BatmanAoD 3y ago
  That's...not...how threads or async work...? > Blocking I/O executed on another thread, with a callback to execute when done, becomes async I/O (from the user's PoV). That's not what we're talking about when we discuss languages with async I/O, though. That's just bog-standard synchronous I/O with multithreading. > The read/write operations are still potentially blocking, so for efficiency you need multiple threads. That doesn't actually follow. The entire point of language-level async I/O is to be able to continue doing other work while waiting for the kernel to finish an I/O operation, without spawning a new OS thread just for this purpose.

bad_user 3y ago

> You cannot, (should not), do blocking IO in async in any language. On platforms with 1:1 scheduling, of course you can. Blocking I/O executed on another thread, with a callback to execute when done, becomes async I/O (from the user's PoV). Ofc, when we talk about async I/O, we also refer to the kernel APIs being used, such as select/poll/epoll/io_uring. Say, working with Epoll is usually done via a single-threaded "event loop", but that only listens for the operations possible for an open file/socket. The read/write operations are still potentially blocking, so for efficiency you need multiple threads. The dirty secret is that async I/O, as implemented by Linux, isn't actually fully async.

BatmanAoD 3y ago
That's...not...how threads or async work...? > Blocking I/O executed on another thread, with a callback to execute when done, becomes async I/O (from the user's PoV). That's not what we're talking about when we discuss languages with async I/O, though. That's just bog-standard synchronous I/O with multithreading. > The read/write operations are still potentially blocking, so for efficiency you need multiple threads. That doesn't actually follow. The entire point of language-level async I/O is to be able to continue doing other work while waiting for the kernel to finish an I/O operation, without spawning a new OS thread just for this purpose.