2008-10-10 11 views

Respuesta

20

Una diferencia que conozco, es que las tuberías con nombre en Linux son entradas reales en el sistema de archivos (lo verás en una lista de directorios, tienen un tipo especial), mientras que en Windows están almacenadas en algún repositorio en algún lugar (se accede a todos a través de la ruta "\\. \ pipe \".

En segundo lugar, en Linux puede simplemente escribir/leer de las tuberías como si se tratara de cualquier otro archivo, utilizando el archivo estándar de métodos IO. en Windows, tiene que usar las funciones especiales 'Pipe' que son parte de la API de Win32.

Me gusta mejor el método de Linux porque me permite usar pipes con cualquier aplicación que desee. Por ejemplo:

mkfifo pipe.wav 
decodeMP3 song.mp3 --out pipe.wav & 
encodeAVI video.mpeg pipe.wav --out video.avi 

Esto me permite canalizar la salida del decodificador de MP3 directamente en el decodificador de video, en lugar de tener que decodificar primero todo el MP3 en un archivo WAV en el disco. Es útil si tienes una CPU de doble núcleo, porque entonces estás ejecutando ambas operaciones a la vez, para una agradable aceleración.

+1

Votación descendente. En Windows, puedo usar la función CreateFile, ReadFile, WriteFile, ReadFileEx, WriteFileEx para canalizaciones con nombre. Solo el servidor debe usar CreateNamedPipe. Existen funciones de tuberías para la sincronización de la creación y el enlace de tuberías, pero pueden sustituirse por el uso de eventos de espera nombrados si no se necesitan tuberías en red. –

+1

Y las Tuberías con nombre locales de Windows usan archivos de memoria mapeados debajo. Significa que la tubería almacena datos en la memoria o en pagefile.sys. –

+0

En lugar de utilizar un sistema de archivos raíz, Windows tiene un árbol de objetos raíz que se conserva en el registro y se llena dinámicamente. El '' \\. \ '' Y '' \\?\ '' Los prefijos tipo UNC (en realidad no son UNC) se asignan al directorio virtual del administrador de objetos nativo '\ ??'. Esto se ve en los enlaces de su dispositivo de sesión de inicio de sesión en '\ Sessions \ 0 \ DosDevices \ [LOGON ID]' y luego los enlaces del dispositivo del sistema en '\ Global ??'. – eryksun

5

En Linux (y * ix en general), "todo es un archivo". Puede leer/escribir/buscar tuberías y tomas de corriente y dispositivos sin restricciones, en la medida en que esas operaciones tengan sentido.

Considerando que Windows tiene una arquitectura mucho menos unificada para estos diferentes tipos de objetos. Aunque no pude decirle los detalles, sé que el almacenamiento en búfer de las tuberías es considerablemente diferente entre Windows y Linux, por lo que puede encontrarse con dificultades allí.

Además, un uso común de Unix-y de tubos es a fork() un subproceso y luego se comunica con él a través de una tubería (el elemento primario abre un extremo, el elemento secundario abre el otro extremo). En Windows, ese tipo de cosas simplemente no es posible. Los mecanismos de IPC son bastante diferentes.

+1

Un proceso hijo en Windows obviamente puede heredar un identificador de pipa, así que supongo que quiere decir 'fork()' no es posible. El grano puede bifurcarse; es un uso bastante sencillo de los servicios básicos del administrador de memoria, pero implementarlo en la API de Windows es probablemente casi imposible. Incluso en Unix, el uso incorrecto de la horquilla puede ser un desastre, y eso es en un sistema que fue diseñado para ello donde la gente está creando soluciones pensando en la horquilla. – eryksun

1

Otra diferencia importante

bajo Windows

A | B | C 

hasta que una se hace con su outpu t B no se inicia la lectura, la misma para la salida B siendo leído por C

* nix engancha la entrada y salida juntos para que C puede leer la salida y B de B puede leer la salida de A, mientras que A y B están aún en marcha

El rendimiento es aproximadamente el mismo, pero la salida se muestra más rápido con * nix.

Cuestiones relacionadas