Is writing to a socket an arbitrary limitation of the sendfile() syscall?
- by Sufian
Prelude
sendfile() is an extremely useful syscall for two reasons:
First, it's less code than a read()/write() (or recv()/send() if you prefer that jive) loop.
Second, it's faster (less syscalls, implementation may copy between devices without buffer, etc...) than the aforementioned methods.
Less code. More efficient. Awesome.
In UNIX, everything is (mostly) a file. This is the ugly territory from the collision of platonic theory and real-world practice. I understand that sockets are fundamentally different than files residing on some device. I haven't dug through the sources of Linux/*BSD/Darwin/whatever OS implements sendfile() to know why this specific syscall is restricted to writing to sockets (specifically, streaming sockets).
I just want to know...
Question
What is limiting sendfile() from allowing the destination file descriptor to be something besides a socket (like a disk file, or a pipe)?
