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