Also, I can count on one hand the number of programmers I trust to use O_NONBLOCK
Top-level
10 comments
One last tip: the purpose of async I/O is to give the CPU back to your program while the I/O operation completes. But if you don't have a plan for what to do with the CPU while you have it, you don't need async I/O. Async I/O is also often used for I/O multiplexing, which is when you have more than one source of I/O and want to have several I/O operations in flight at the same time, but otherwise you don't need the CPU while they work. You don't need async I/O for that, you need poll(2). @drewdevault I'd disagree here, a program can be I/O bound (let's say small requests to a slow service / on a slow network), but you might still want to e.g. accept input from the user while the slow service is doing its thing. If you don't have threads or async i/o, you're waiting on the network while the user thinks your program is broken. @miki bzzzzzt, wrong You want I/O multiplexing to address this case, which is not the same thing as async I/O. @drewdevault how exactly does async I/O differ from I/O multiplexing in your understanding? I/O multiplexing is IIUC having a single thread of execution and using poll() / epoll() / select() / ... to periodically check which I/O is ready and then handling that (either directly or via callbacks). Most nontrivial programs that do that do it via callbacks and an event loop. 1/2 @drewdevault You don't need them for parallelism to utilize resources well. You might still want/need them for a simpler programming model. @drewdevault This is precisely while @pidgin is moving from sockets to the GSocket abstraction. BSD sockets are too easy to get wrong. |
@drewdevault io_uring magically fixes everything and makes it faster 😉