4 ms·
Allready in 1983, 4.2BSD had 3 different attempts at doing multiplexed/asynchronous I/O: Non-blocking I/O: "O_NONBLOCK" with "EWOULDBLOCK" (or "EAGAIN") Signa
by adrian_b 3mo ago
Allready in 1983, 4.2BSD had 3 different attempts at doing multiplexed/asynchronous I/O:
Non-blocking I/O: "O_NONBLOCK" with "EWOULDBLOCK" (or "EAGAIN")
Signal-driven I/O: "O_ASYNC" with "SIGIO"
Synchronous I/O multiplexing: "select()"
All 3 had various defects, especially with a large number of concurrent I/O actions.
In UNIX-derived operating systems, after 1983 there have been many other attempts to implement something better than these 3 (starting with System V "poll" and with POSIX AIO, and then with various incompatible approaches in Solaris, FreeBSD and Linux), but none were good enough and most were seriously inferior to methods of doing asynchronous I/O that existed in some IBM and DEC operating systems decades earlier.
In my opinion, only io_uring has finally solved the problem of multiplex asynchronous I/O in Linux, and in a manner much better than in all older operating systems. I consider all the many older alternatives that exist for liburing as obsolete.
- sscaryterry 3mo agoThis. I'd break-out in a cold sweat if I had to work on this again.
- celiacFun 3mo agoWindows has a better async I/O implementation than Linux and has for decades
- jchw 3mo agoNo, although this was true until around 2019 when Linux introduced io_uring and finally had a genuine innovation. io_uring wound up giving us a unified asynchronous I/O layer that handles just tons of things. (And it is genuinely a step up from the overlapped I/O APIs of Windows, as it avoids eating syscall transition overhead in many cases.) Of course, Microsoft then went on to introduce IORing in 2022, continuing their legacy of never being afraid to adopt good ideas. But still - it would be wrong to suggest Linux is currently behind on async I/O. It hasn't been for years.