¿Escribir en un socket es una limitación arbitraria de la llamada al sistema sendfile()?
-
18-09-2019 - |
Pregunta
Preludio
sendfile()
es una llamada al sistema extremadamente útil por dos razones:
Primero, es menos codigo que un read()
/write()
(o recv()
/send()
si prefieres ese jive) bucle.
En segundo lugar, es más rápido (menos llamadas al sistema, la implementación puede copiarse entre dispositivos sin buffer, etc...) que los métodos antes mencionados.
Menos código.Más eficiente.Impresionante.
En UNIX, todo es (principalmente) un archivo.Este es el territorio feo de la colisión entre la teoría platónica y la práctica del mundo real.Entiendo que los sockets son fundamentalmente diferentes a los archivos que residen en algún dispositivo.No he investigado las fuentes de Linux/*BSD/Darwin/cualquier sistema operativo que implemente sendfile()
para saber por qué esta llamada al sistema específica está restringida a escribir en sockets (específicamente, sockets de transmisión).
Sólo quiero saber...
Pregunta
que es limitante sendfile()
¿Permitir que el descriptor del archivo de destino sea algo más que un socket (como un archivo de disco o una tubería)?
Solución
En el fondo, lo único que limita es que "Nadie está escrito el código todavía".
Sin embargo, supongo que la razón de que no hay-unos escriben el código para esos dos casos que mencionas es que ambos requerirían los datos a copiar, que elimina gran parte de la ventaja de utilizar sendfile
en el primer lugar.
-
Para una
sendfile
-archivo a archivo, se necesitaría una copia porque de lo contrario la misma página tendría que estar en la memoria intermedia de páginas tanto como una página en blanco en el archivo de origen y una página sucia en el archivo de destino . No creo que la memoria intermedia de páginas está construida para manejar ese caso, en el momento (aunque, por supuesto, esto podría ser cambiado si había suficiente motivación). -
Para una
sendfile
-archivo-de tubería, se necesita una copia sin tener en cuenta debido a que el proceso de destino necesita para obtener una copia privada, se puede escribir de los datos. De todos modos, para la mayoría de usos de este caso ya tenemosmmap
.
Otros consejos
Me parece recordar que era una limitación introducida a principios de Linux 2.6 (2.4 no tienen la limitación).
Desde 2.6.17 Linux tiene la llamada al sistema de empalme () que es similar; más flexible, pero un poco menos eficiente. Linus habló de la reimplementación sendfile en términos de empalme (). Ver http://kerneltrap.org/node/6505