¿Cuál es el ingenio exacto de la tubería Unix?


52

He escuchado la historia de cómo Douglas Mcllroy ideó el concepto y cómo Ken Thompson lo implementó en una noche.

Según tengo entendido, pipe es una llamada al sistema que comparte un trozo de memoria entre dos procesos donde un proceso escribe y otro lee.

Como alguien que no está familiarizado con los aspectos internos o los conceptos del sistema operativo, me preguntaba cuál es exactamente el "genio" en la historia. ¿Es la idea de dos procesos que comparten memoria? ¿O es la implementación? ¿O ambos?

PD: Soy consciente de la utilidad de la tubería o de cómo usarla en shell. La pregunta es sobre el concepto y la implementación de|


44
Supongo que en esos primeros días, fue bastante radical presionar fuertemente para implementar un mecanismo para componer aplicaciones. Para hacerlo, necesitaría tener una concepción bien formada de separar la interfaz de la implementación y darse cuenta de la utilidad de la composición funcional en la programación.
Chan-Ho Suh

44
No solo eso, ya que las aplicaciones, mientras se ejecutaban, tenían un identificador de entrada estándar y un identificador de salida estándar, y las API del sistema operativo tipo Unix tenían funciones de lectura / escritura para aplicar a estos identificadores. El uso inteligente de algunos conceptos ortogonales y altamente capaces (manijas, salida y entrada de ellos) conduce no solo a tuberías, sino también a enchufes, interacciones entre dispositivos y caracteres, y docenas de otras cosas. Entonces, ahora que tenemos identificadores de archivos (para el tty que proporciona entrada de teclado y salida de texto) compongamos las aplicaciones para que una aplicación se convierta en el tty de la otra.
Warren P

66
@WarrenP En realidad, Unix obtuvo entrada y salida estándar debido a la pipe()llamada al sistema y al |operador de shell (ref: McIlroy ). O, como Voltaire podría haber dicho, " Si [stdio] no existiera, sería necesario inventarlo " . :-)
Ross Patterson

¿No había tal cosa como un identificador de archivo, y un identificador de entrada y salida hasta DESPUÉS de las tuberías?
Warren P

44
@WarrenP: Parece que lo que dice Patterson es esto: primero hubo identificadores de archivos. Luego, a estos chicos se les ocurrió la idea de que cada programa tiene un identificador de entrada y un identificador de salida de forma predeterminada, lo que permite que los programas se encadenen trivialmente. Estos se conocieron como la entrada / salida "estándar".
Mooing Duck

Respuestas:


109

Según tengo entendido, pipe es una llamada al sistema que comparte un trozo de memoria entre dos procesos donde un proceso escribe y otro lee.

En realidad, no hay memoria compartida involucrada. El lector y el escritor NO están compartiendo ninguna parte de su espacio de direcciones, y no están utilizando ninguna sincronización explícita.

Los procesos de lectura y escritura están haciendo ready las writellamadas al sistema exactamente como lo harían si estuvieran leyendo / escribiendo en un archivo. ESO es el genio ... la innovación: la noción de que (simple) la comunicación entre procesos y la E / S de archivos se pueden manejar de la misma manera ... desde la perspectiva del programador de aplicaciones y el usuario.

Una vez que se ha configurado la tubería, el sistema operativo (no el código de aplicación o las bibliotecas en el espacio de usuario) se encarga del almacenamiento en búfer y la coordinación. Transparentemente.


Por el contrario, antes de la invención del concepto de tubería, si necesitara hacer un procesamiento de "tubería", normalmente tendría una salida de escritura de aplicación en un archivo, y luego, cuando haya terminado, ejecutaría la segunda aplicación para leer archivo.

Alternativamente, si desea una tubería verdadera, puede codificar ambas aplicaciones para configurar un segmento de memoria compartida (real) y usar semáforos (o algo así) para coordinar la lectura / escritura. Complicado ... y, como consecuencia, no se hace con frecuencia.


34
"ESO es el genio ... la innovación: la noción de que la comunicación entre procesos y la E / S de archivos se pueden manejar de la misma manera", exactamente esto. Le permite tener comunicación entre procesos entre programas que nunca fueron diseñados para tenerla, y ni siquiera (necesita) saber qué está sucediendo.
Guntram Blohm apoya a Monica el

66
También es útil tener en cuenta que el motivo por el que se usa la E / S de archivos para IPC fue principalmente útil porque Unix fue diseñado para el procesamiento de texto , ya que transmite datos de texto de un programa a otro, lo que permite una composición relativamente indolora, lo que a su vez significa que todo el sistema podría construirse a partir de programas relativamente simples y pequeños que transmiten datos de uno a otro en (posiblemente) largas cadenas de operaciones simples. Básicamente, significaba que tenía un lenguaje relativamente flexible para manejar el procesamiento de texto.
Luaan

1
Y así, el "ingenio de la tubería Unix" es el "ingenio de Unix": todas las E / S (incluida la comunicación entre procesos, los archivos estándar y el resto de los objetos del sistema de archivos) se manejan como archivos.
Mark Hurd

Otro golpe de genio fue que UNIX abogó por estructuras de archivos legibles por humanos en un momento en que cada byte contaba ...
EvertW

14

En mi opinión, el genio de la idea de "tuberías" es la simplicidad de uso.

No tiene que hacer ninguna llamada al sistema, asignar memoria, nada complicado en absoluto. En el shell, se utiliza un solo carácter: |. Esto le otorga un poder extraordinario en la combinación de herramientas simples (o complejas) para una tarea determinada.

Tome algunas tareas cotidianas comunes, como ordenar el texto de forma ordenada. Es posible que tenga un comando que enumere un montón de nombres. (Para mi ejemplo, usaré un archivo que contiene un montón de nombres, cortesía de listofrandomnames.com). Usando tuberías puede hacer algo como lo siguiente:

$ cat names.txt
Sally Weikel
Dana Penaflor
Christine Hook
Shaneka Flythe
Almeda Crook
Freddie Lindley
Hester Kersh
Wanda Ruse
Megan Mauzy
Samuel Mancha
Paris Phipps
Annika Accardo
Elena Nabors
Caroline Foti
Jude Nesby
Chase Gordy
Carmela Driggers
Marlin Ostendorf
Harrison Dauber
$ cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100
Accardo, Annika     Hook, Christine     Ostendorf, Marlin
Crook, Almeda       Kersh, Hester       Penaflor, Dana
Dauber, Harrison    Lindley, Freddie    Phipps, Paris
Driggers, Carmela   Mancha, Samuel      Ruse, Wanda
Flythe, Shaneka     Mauzy, Megan        Weikel, Sally
Foti, Caroline      Nabors, Elena
Gordy, Chase        Nesby, Jude

Esto es sólo un ejemplo; hay miles. Para algunas otras tareas específicas que se hacen notablemente más fáciles mediante el uso de tuberías, consulte la sección "La filosofía de Unix" en esta página .


Para subrayar esta respuesta, vea las diapositivas 4 a 9 de la presentación, "Por qué Zsh es más genial que su caparazón".


Soy consciente de que el comando anterior incluye un UUOC . Lo dejé en reposo porque es un marcador de posición para un comando arbitrario que genera texto.


3
Pequeña nota : sort -upuede hacer el trabajo sort | uniqmás rápido.
Iwillnotexist Idonotexist

cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100Puede que estés acostumbrado, pero no lo llamaría simple en absoluto. Especialmente la awkparte.
Federico Poloni

Las tuberías son simples. Dije: "... poder extraordinario en la combinación de herramientas simples (o complejas) para una tarea determinada".
Comodín

5

Así que intenté investigar un poco sobre esto buscando manuales PDP-10 / TOPS-10 para averiguar cuál era el estado del arte antes de las tuberías. Encontré esto , pero TOPS-10 es notablemente difícil de google. Hay algunas buenas referencias sobre la invención de la tubería: una entrevista con McIlroy , sobre la historia y el impacto de UNIX .

Tienes que poner esto en contexto histórico. Pocas de las herramientas y comodidades modernas que damos por sentado existieron.

"Al principio, Thompson ni siquiera programó en el PDP, sino que utilizó un conjunto de macros para el ensamblador GEMAP en una máquina GE-635". (29) Se generó una cinta de papel en el GE 635 y luego se probó en el PDP-7 hasta que, según Ritchie, "se completó un núcleo Unix primitivo, un editor, un ensamblador, un shell simple (intérprete de comandos) y algunas utilidades (como los comandos Unix rm, cat, cp). En este momento punto, el sistema operativo era autosuficiente, los programas podían escribirse y probarse sin recurrir a la cinta de papel, y el desarrollo continuó en el PDP-7 ".

Un PDP-7 se ve así . Tenga en cuenta la falta de una pantalla interactiva o disco duro. El "sistema de archivos" se almacenaría en la cinta magnética. Había hasta 64kB de memoria para programas y datos.

En ese entorno, los programadores tendían a abordar el hardware directamente, por ejemplo, emitiendo comandos para girar la cinta y procesar los caracteres uno a la vez, leídos directamente desde la interfaz de la cinta. UNIX proporcionó abstracciones sobre esto, de modo que en lugar de "leer desde el teletipo" y "leer desde la cinta" siendo interfaces separadas, se combinaron en una sola, con la adición crucial de "leer desde la salida de otro programa sin almacenar una copia temporal en el disco" o cinta ".

Aquí está McIlroy sobre la invención de grep. Creo que esto hace un buen trabajo al resumir la cantidad de trabajo requerida en el entorno anterior a UNIX.

"Grep fue inventado para mí. Estaba haciendo un programa para leer texto en voz alta a través de un sintetizador de voz. A medida que inventaba las reglas fonéticas, buscaba en el diccionario Webster palabras en las que pudieran fallar. Por ejemplo, ¿cómo manejas el dígrafo? ui ', que se pronuncia de muchas maneras diferentes:' fruta ',' astucia ',' culpable ',' angustia ',' intuición ',' beguina ': dividiría el diccionario en pedazos que encajen en el limitado búfer y uso de ed un comando global para seleccionar una lista. Reduciría esta lista mediante escaneos repetidos con ed para ver cómo funciona cada regla propuesta ".

"El proceso fue tedioso y terriblemente despilfarrador, ya que el diccionario tuvo que dividirse (uno no podía permitirse dejar una copia dividida en línea). Luego ed copió cada parte en / tmp, la escaneó dos veces para cumplir el comando g, y finalmente lo tiré, lo que también lleva tiempo ".

"Una tarde le pregunté a Ken Thompson si podía sacar el reconocimiento de expresiones regulares del editor y hacer un programa de una pasada para hacerlo. Dijo que sí. A la mañana siguiente encontré una nota en mi correo anunciando un programa llamado grep. Funcionó de maravilla. Cuando se le preguntó qué significaba ese nombre gracioso, Ken dijo que era obvio. Representaba el comando del editor que simulaba, g / re / p (impresión de expresión regular global) ".

Compare la primera parte de eso con el cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100ejemplo. Si sus opciones son "construir una línea de comando" versus "escribir un programa específicamente para ese propósito, a mano, en ensamblador", entonces vale la pena construir la línea de comando. Incluso si lleva unas horas leer los manuales (en papel) para hacerlo. Luego puede escribirlo para referencia futura.


1

El genio de Pipes es que combina tres ideas importantes.

Primero, las tuberías son una implementación práctica de 'co-rutinas', un término acuñado por Conway en 1958 que era prometedor pero que tenía poco uso práctico antes de las tuberías.

En segundo lugar, al implementar tuberías en el lenguaje de shell, Thompson et al inventaron el primer "lenguaje de pegamento" real.

Estos dos puntos permiten que los componentes de software reutilizables se desarrollen eficientemente en un lenguaje optimizado de bajo nivel, y luego se peguen para formar una funcionalidad mucho más grande y compleja. Llamaron a esto 'Programación en grande'.

En tercer lugar, la implementación de canalizaciones utilizando las mismas llamadas al sistema que se usaron para el acceso a archivos permitió que los programas se escribieran con interfaces universales. Esto permitió soluciones verdaderamente universales a los problemas de software, que se pueden usar de forma interactiva, utilizando datos de archivos y como parte de sistemas de software más grandes, todo sin un solo cambio en los componentes del software. Sin compilación, sin configuración, solo unos pocos comandos de shell simples.

Si le interesa pasar por la curva de aprendizaje, el software UNIX es tan útil hoy como lo fue hace 40 años. Estamos constantemente reinventando cosas que ya sabían y para las que creamos soluciones. Y el avance clave fue la simple tubería. La única innovación real después de eso fue la creación de Internet en los años 80. Dramáticamente, UNIX falló su implementación de eso al crear una API separada. Todavía sufrimos las consecuencias ... Oh, sí, había algo con pantallas de video y ratones que se hizo popular a finales de los 80. Pero eso es para WIMPs.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.