En ingeniería de software , una tubería consiste en una cadena de elementos de procesamiento ( procesos , hilos , corrutinas , funciones , etc. ), dispuestos de modo que la salida de cada elemento sea la entrada del siguiente. El concepto es análogo a una tubería física. Por lo general, se proporciona cierta cantidad de almacenamiento en búfer entre elementos consecutivos. La información que fluye en estas tuberías es a menudo un flujo de registros , bytes o bits , y los elementos de una tubería pueden llamarse filtros . Esto también se llama patrón de diseño de tuberías y filtros, que es monolítico . Sus ventajas son la simplicidad y el bajo costo, mientras que sus desventajas son la falta de elasticidad , tolerancia a fallas y escalabilidad . [1] La conexión de elementos en una tubería es análoga a la composición de funciones .
En términos estrictos, una tubería es lineal y unidireccional, aunque a veces el término se aplica a flujos más generales. Por ejemplo, una tubería principalmente unidireccional puede tener alguna comunicación en la otra dirección, conocida como canal de retorno o backchannel, como en el truco del analizador léxico , o una tubería puede ser completamente bidireccional. Los flujos con árboles unidireccionales y topologías de grafos acíclicos dirigidos se comportan de manera similar a las tuberías lineales. La falta de ciclos en dichos flujos los hace simples y, por lo tanto, se los puede denominar vagamente "tuberías".
Las canalizaciones se implementan a menudo en un sistema operativo multitarea , lanzando todos los elementos al mismo tiempo que los procesos y atendiendo automáticamente las solicitudes de lectura de datos de cada proceso con los datos escritos por el proceso ascendente. Esto puede llamarse una canalización multiprocesada. De esta manera, el programador cambiará naturalmente la CPU entre los procesos para minimizar su tiempo de inactividad. En otros modelos comunes, los elementos se implementan como subprocesos livianos o como corrutinas para reducir la sobrecarga del sistema operativo que a menudo implican los procesos. Dependiendo del sistema operativo, los subprocesos pueden programarse directamente por el sistema operativo o por un administrador de subprocesos. Las corrutinas siempre son programadas por un administrador de corrutinas de algún tipo.
Las solicitudes de lectura y escritura suelen ser operaciones bloqueantes. Esto significa que la ejecución del proceso de origen, al escribir, se suspende hasta que se puedan escribir todos los datos en el proceso de destino. Del mismo modo, la ejecución del proceso de destino, al leer, se suspende hasta que se pueda obtener al menos parte de los datos solicitados del proceso de origen. Esto no puede dar lugar a un punto muerto , en el que ambos procesos esperarían indefinidamente a que el otro responda, ya que al menos uno de los procesos pronto tendrá su solicitud atendida por el sistema operativo y seguirá ejecutándose.
Para mejorar el rendimiento, la mayoría de los sistemas operativos que implementan tuberías utilizan búferes de tuberías , que permiten que el proceso de origen proporcione más datos de los que el proceso de destino puede o desea recibir en ese momento. En la mayoría de los sistemas operativos Unix y similares, también está disponible un comando especial, normalmente llamado "buffer", que implementa un búfer de tuberías de un tamaño potencialmente mucho mayor y configurable. Este comando puede ser útil si el proceso de destino es significativamente más lento que el proceso de origen, pero se desea que el proceso de origen complete su tarea lo antes posible. Por ejemplo, si el proceso de origen consiste en un comando que lee una pista de audio de un CD y el proceso de destino consiste en un comando que comprime los datos de audio en forma de onda a un formato como MP3 . En este caso, almacenar en búfer toda la pista en un búfer de tuberías permitiría que la unidad de CD se detenga más rápidamente y permitiría al usuario retirar el CD de la unidad antes de que finalice el proceso de codificación.
Este comando de buffer se puede implementar mediante llamadas del sistema para leer y escribir datos. Se pueden evitar esperas ineficientes mediante el uso de funciones como poll o select o multithreading .
Algunos ejemplos notables de sistemas de software de canalización incluyen:
CMS Pipelines es una adaptación de la idea de pipeline a los sistemas VM/CMS y z/OS . Admite estructuras de pipeline mucho más complejas que los shells de Unix, con pasos que toman múltiples flujos de entrada y producen múltiples flujos de salida. (Esta funcionalidad es compatible con el núcleo de Unix, pero pocos programas la utilizan ya que genera sintaxis complicada y modos de bloqueo, aunque algunos shells la admiten mediante la asignación arbitraria de descriptores de archivos ).
Los programas de aplicación tradicionales en los sistemas operativos mainframe de IBM no tienen flujos de entrada y salida estándar que permitan la redirección o la canalización. En lugar de generar procesos con programas externos, CMS Pipelines cuenta con un despachador liviano para ejecutar simultáneamente instancias de más de 200 programas integrados que implementan utilidades UNIX típicas e interactúan con dispositivos y servicios del sistema operativo. Además de los programas integrados, CMS Pipelines define un marco para permitir programas REXX escritos por el usuario con flujos de entrada y salida que se pueden usar en la canalización.
Los datos de los mainframes de IBM suelen residir en un sistema de archivos orientado a registros y los dispositivos de E/S conectados funcionan en modo de registro en lugar de en modo de flujo. En consecuencia, los datos en CMS Pipelines se gestionan en modo de registro. En el caso de los archivos de texto, un registro contiene una línea de texto. En general, CMS Pipelines no almacena los datos en búfer, sino que pasa registros de datos en forma escalonada de un programa al siguiente. Esto garantiza un flujo determinista de datos a través de una red de canales interconectados.
Además de las canalizaciones basadas en secuencias de bytes, también existen canalizaciones de objetos. En una canalización de objetos, los elementos de procesamiento generan objetos en lugar de texto. PowerShell incluye una canalización de objetos interna que transfiere objetos .NET entre funciones dentro del entorno de ejecución de PowerShell. Los canales , que se encuentran en el lenguaje de programación Limbo , son otros ejemplos de esta metáfora.
Los entornos gráficos como RISC OS y ROX Desktop también utilizan pipelines. En lugar de proporcionar un cuadro de diálogo de guardado que contenga un administrador de archivos para permitir al usuario especificar dónde debe escribir datos un programa , RISC OS y ROX proporcionan un cuadro de diálogo de guardado que contiene un icono (y un campo para especificar el nombre). El destino se especifica arrastrando y soltando el icono. El usuario puede soltar el icono en cualquier lugar donde se pueda soltar un archivo ya guardado, incluso sobre iconos de otros programas. Si el icono se suelta sobre el icono de un programa, se carga y el contenido que de otro modo se habría guardado se pasa al flujo de entrada estándar del nuevo programa.
Por ejemplo, un usuario que esté navegando por la red mundial puede encontrarse con una imagen comprimida en formato .gz que desee editar y volver a cargar. Mediante el uso de canales de interfaz gráfica de usuario, podría arrastrar el enlace a su programa de desarchivado, arrastrar el icono que representa el contenido extraído a su editor de imágenes , editarlo, abrir el cuadro de diálogo Guardar como y arrastrar su icono a su software de carga.
En teoría, este método podría utilizarse con un cuadro de diálogo de guardado convencional, pero esto requeriría que los programas del usuario tuvieran una ubicación obvia y de fácil acceso en el sistema de archivos. Como esto no suele ser así, las secuencias de comandos GUI son poco frecuentes.
El nombre "tubería" proviene de una analogía aproximada con la plomería física, en el sentido de que una tubería generalmente [2] permite que la información fluya en una sola dirección, como el agua a menudo fluye en una tubería.
Las tuberías y los filtros pueden considerarse una forma de programación funcional , que utiliza flujos de bytes como objetos de datos. Más específicamente, pueden considerarse como una forma particular de mónada para E/S . [3]
El concepto de canalización también es central para el marco de desarrollo web Cocoon o para cualquier implementación de XProc (los estándares del W3C), donde permite modificar un flujo de origen antes de su visualización final.
Este patrón fomenta el uso de secuencias de texto como entrada y salida de los programas. Esta dependencia del texto debe tenerse en cuenta al crear estructuras gráficas para programas de texto.