title: Is writing to a socket an arbitrary limitation of the sendfile() syscall?
body: <p><strong>Prelude</strong></p>
  
  <p><code>sendfile()</code> is an extremely useful syscall for two reasons:</p>
  
  <p>First, it's <em>less code</em> than a <code>read()</code>/<code>write()</code> (or <code>recv()</code>/<code>send()</code> if you prefer that jive) loop.<br>
  Second, it's <em>faster</em> (less syscalls, implementation may copy between devices <em>without</em> buffer, etc...) than the aforementioned methods.</p>
  
  <p>Less code.  More efficient.  Awesome.</p>
  
  <p>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 <code>sendfile()</code> to know why this specific syscall is restricted to writing to sockets (specifically, streaming sockets).</p>
  
  <p>I just want to know...</p>
  
  <p><strong>Question</strong></p>
  
  <p>What is limiting <code>sendfile()</code> from allowing the destination file descriptor to be something besides a socket (like a disk file, or a pipe)?</p>