3 ms·
I've written event-driven, non-blocking style C for a couple of different projects on POSIX platforms. When a file descriptor becomes readable, you read from it
by sebcat 9y ago
I've written event-driven, non-blocking style C for a couple of different projects on POSIX platforms. When a file descriptor becomes readable, you read from it until read(2) returns EAGAIN[1] or until a condition is fulfilled, such as the read buffer containing a delimiter. People new to event-driven programming may just invoke read(2) once for each readable event, check for a condition and then yield to the event loop. This sounds like the same mistake, only with more turtles stacked on top of it.
[1] This applies to sockets and pipes (incl. stdin), not regular file I/O which usually ends up being off-loaded to a thread/process pool (if needed)
- 0xcde4c3db 9y agoI don't think it's quite the same thing, but that description reminds me of Ted Unangst's "accidentally nonblocking" post. https://www.tedunangst.com/flak/post/accidentally-nonblocking https://www.tedunangst.com/flak/post/accidentally-nonblockin...
- hetman 9y agoI think this is a bit different. Even if the file reading code was reading the maximum amount of available data it would still have to store most of it in a local buffer and then yield only one line in a promise which would mean only one line was being processed per event loop tick. There's one more thing you should be aware of here that can catch a lot of developers out. On most POSIX systems, file reads from disk do not return EAGAIN but will in fact block if the disk is too slow returning the data back. EAGAIN is only meaningful on things like pipes, sockets, etc. The only way I'm aware of to do disk access truely asynchronously is using the POSIX AIO interface.