Typically, I've found, the common operation is not so much the file/HANDLE itself, as that the file/HANDLE can generate operations that you need to wait on. But

Typically, I've found, the common operation is not so much the file/HANDLE itself, as that the file/HANDLE can generate operations that you need to wait on. But select() set the stage by waiting on the file descriptor, and poll/epoll mostly follow suit. You register interest in events on an FD. (Instead of, say, starting an operation and saying "tell me when this operation finishes"; e.g., "futures" as exposed by a number of languages. Aside from waiting, I'd say passing/referring to the objects being operated on is also a commonality. Passing a FD to a child process, for example, or giving it (the object, be that a file/pipe/socket/timer/process/etc.) a name in the FS s.t. other things can refer to them by name. (I personally wish though that fork()/exec() had forced you to specify exactly the set of objects (files/etc.) for the child to avoid the entire multithreading/close-on-exec/atomic flag setting hell that exists today.) I don't know that read/write are actually abstract at the level of a "file descriptor" though. Eventfds and timerfds both support them, but it feels forced. Pipes are one-way, so one of read/write don't make sense, and seek on pipe doesn't either. I think some file descriptors (child classes of a generic "object"/FD/HANDLE, such as files) support read/write, but not necessarily all FDs support read/write/seek.