Is writing to a socket an arbitrary limitation of the sendfile() syscall?

Posted by Sufian on Stack Overflow See other posts from Stack Overflow or by Sufian
Published on 2009-12-09T21:23:25Z Indexed on 2010/03/29 14:33 UTC
Read the original article Hit count: 367

Filed under:
|
|
|
|

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)?

© Stack Overflow or respective owner

Related posts about unix

Related posts about syscall