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

Prelude

sendfile() - an extremely useful system call for two reasons:

Firstly, this is less code than the read()/ write()(or recv()/ loop send()if you prefer this jive).
Secondly, it is faster (fewer system calls, an implementation can copy between devices without a buffer, etc.) than the above methods.

Less code. More effective. Tall.

On UNIX, everything is (basically) a file. This is an ugly territory from the clash of Platonic theory and real practice. I understand that sockets are fundamentally different from files located on some device. I did not dig out the Linux / * BSD / Darwin / sources regardless of what the OS implements sendfile()to know why this particular scenario is limited to writing to sockets (in particular, streaming sockets).

I just want to know...

Question

What limits sendfile()the resolution of the destination file descriptor to be something other than a socket (for example, a disk or channel file)?

+3
source share
2 answers

, , , , " ".

, , , , , , sendfile .

  • sendfile , pagecache , . , pagecache (, , , ).

  • -to-pipe sendfile , , . , mmap.

+3

, , , Linux 2.6 ( 2.4 ).

2.6.17 Linux splice(), ; , . sendfile splice(). . http://kerneltrap.org/node/6505

+4

Source: https://habr.com/ru/post/1725220/


All Articles