L'écriture à une prise une limitation arbitraire du sendfile () syscall?

Question

Prelude

sendfile() est un syscall extrêmement utile pour deux raisons:

D'abord, il est moins de code d'un read() / write() (ou recv() / send() si vous préférez que jive) boucle.
En second lieu, il est plus rapide (moins syscalls, la mise en œuvre peuvent copier entre les périphériques sans tampon, etc ...) que les méthodes mentionnées ci-dessus.

Moins de code. Plus efficace. Impressionnant.

Dans UNIX, tout est (surtout) un fichier. Ceci est le territoire laid de la collision de la théorie platonicienne et la pratique dans le monde réel. Je comprends que les prises sont fondamentalement différents que les fichiers résidant sur un périphérique. Je n'ai pas creusé à travers les sources de Linux / * BSD / Darwin / OS tout en œuvre sendfile() savoir pourquoi cette syscall spécifique est limitée à l'écriture à des prises (en particulier, prises en continu).

Je veux juste savoir ...

Question

Qu'est-ce que sendfile() limite de permettant le descripteur de fichier de destination pour être autre chose qu'un socket (comme un fichier de disque, ou un tuyau)?

Answer 1

Au fond, la seule chose qui limite est que « non-son écrit le code encore ».

Cependant, je crois que la raison pour que personne ne les écrit le code pour les deux cas, vous mentionnez que les deux nécessiteraient les données à copier, ce qui élimine une grande partie de l'avantage d'utiliser sendfile en premier lieu.

• Pour un sendfile fichier à fichier, vous auriez besoin d'une copie parce que sinon la même page devrait être dans le pagecache à la fois comme une page propre dans le fichier source et une page sale dans le fichier de destination . Je ne pense pas que le pagecache est conçu pour traiter ce cas au moment (même si bien sûr, cela pourrait être modifié s'il y avait une motivation suffisante).

• Pour un fichier sendfile à pipe, vous avez besoin d'une copie quel que soit parce que le processus de destination doit obtenir une copie privée, inscriptible des données. Quoi qu'il en soit, pour la plupart des utilisations de ce cas, nous avons déjà mmap.

Answer 2

Je crois me souvenir qu'il était une limitation introduite au début de Linux 2.6 (2.4 n'a pas eu la limitation).

Depuis 2.6.17 Linux a l'appel système splice () qui est similaire; plus souple, mais un peu moins efficace. Linus a parlé de sendfile re-mise en œuvre en termes d'épissure (). Voir http://kerneltrap.org/node/6505