io_canread(3)

💖 io_canread — bestie, which fd is ready to spill the tea?

okay so real quick, we're in the Library Functions Manual section, page io_canread(3), and it is exactly what it sounds like: it tells you which file descriptor is ready to be read from. no cap. ✨

🌸 NAME 🌸

io_canread — return a file descriptor that can be read from 🫶

✨ SYNTAX ✨

#include <libowfat/io.h>

int64 io_canread();

that's it, that's the whole signature. int64, no args, she's lowkey elegant 💅

🦋 DESCRIPTION 🦋

so io_canread hands you back the next file descriptor that can be read from. but bestie, there are receipts you gotta have first: you have to have called io_wantread() on that file descriptor earlier, and you have to have called io_wait() or io_waituntil(). no skipping steps, the vibes must be correct. 🎀

what happens under the hood is these functions keep an internal data structure — like a little group chat — of which descriptors the operating system reported as readable. it's giving main character energy for your fds. 👑

⚠️ super important, don't skip this one: there is no guarantee that there's still data you can read from the descriptor. all it means is that there was data back when io_wait() or io_waituntil() got called. another process could've swooped in and read the data before you even got there. 😭 so literally always look at the result from io_tryread().

and if there are no more descriptors that you can write to without blocking, io_canwrite will return -1. when that happens, you should call io_wait() or io_waituntil() again. just loop back around, queen. 🔁

also — and this is the part people get wrong — you should use io_tryread(3) to read from the descriptor, not plain read(2). if you do use read(2) and you get EAGAIN, call io_eagain(3). please. for me. 🙈

🌈 SEE ALSO 🌈

• io_wait(3)
• io_canwrite(3)
• io_eagain(3)

and that's the whole page, bestie!! this little icon was brought to you by the io_canread(3) page from the Library Functions Manual — go forth, check your fds, and slay 💖✨🎀🦋🌸💅🫶