En ingeniería de software , una canalización consta de una cadena de elementos de procesamiento ( procesos , subprocesos , corrutinas , funciones , etc. ), organizados de manera que la salida de cada elemento sea la entrada del siguiente; el nombre es por analogía con 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 estos conductos es a menudo un flujo de registros , bytes o bits , y los elementos de un conducto pueden denominarse filtros ; esto también se denomina patrón de diseño de tuberías y filtros . Conectar elementos en una tubería es análogo a la composición de funciones .
En sentido estricto, 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 canal de retorno, como en el truco de Lexer , o una tubería puede ser completamente bidireccional. Los flujos con topologías de árbol unidireccional y gráficos acíclicos dirigidos se comportan de manera similar a las tuberías (lineales) (la falta de ciclos las hace simples) y, por lo tanto, pueden denominarse vagamente "tuberías".
Los pipelines a menudo se implementan 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 se puede llamar un pipeline multiprocesado. 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 ser programados directamente por el sistema operativo o por un administrador de subprocesos. Las corrutinas siempre las programa un administrador de corrutinas de algún tipo.
Por lo general, las solicitudes de lectura y escritura son operaciones de bloqueo, lo que significa que la ejecución del proceso de origen, al escribir, se suspende hasta que todos los datos puedan escribirse en el proceso de destino y, de la misma manera, la ejecución del proceso de destino, al leer, se suspende hasta que al menos algunos de los datos solicitados puedan obtenerse del proceso fuente. Esto no puede llevar a un punto muerto , donde ambos procesos esperarían indefinidamente a que el otro responda, ya que al menos uno de los dos procesos pronto recibirá su solicitud por parte del sistema operativo y continuará ejecutándose.
Para mejorar el rendimiento, la mayoría de los sistemas operativos que implementan canalizaciones utilizan buffers de canalización , que permiten que el proceso de origen proporcione más datos de los que el proceso de destino puede o desea recibir actualmente. En la mayoría de los sistemas operativos Unices y similares a Unix, también está disponible un comando especial que implementa un búfer de canalización de un tamaño potencialmente mucho mayor y configurable, normalmente llamado "búfer". Este comando puede ser útil si el proceso de destino es significativamente más lento que el proceso de origen, pero de todos modos se desea que el proceso de origen pueda completar su tarea lo antes posible. Por ejemplo, si el proceso de origen consta de un comando que lee una pista de audio de un CD y el proceso de destino consta de un comando que comprime los datos de audio de forma de onda a un formato como MP3 . En este caso, almacenar toda la pista en un búfer de tubería permitiría que la unidad de CD desacelere más rápidamente y permitiría al usuario extraer el CD de la unidad antes de que finalice el proceso de codificación.
Un comando de búfer de este tipo se puede implementar mediante llamadas al sistema para leer y escribir datos. Se puede evitar una espera ocupada y derrochadora mediante el uso de funciones como encuesta , selección o subprocesos múltiples .
Algunos ejemplos notables de sistemas de software de tuberías incluyen:
CMS Pipelines es una adaptación de la idea de canalización a sistemas VM/CMS y z/OS . Admite estructuras de canalización 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 kernel de Unix, pero pocos programas la utilizan, ya que complica la sintaxis y los 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 canalización. En lugar de generar procesos con programas externos, CMS Pipelines presenta un despachador liviano para ejecutar simultáneamente instancias de programas integrados para ejecutar la canalización. Más de 200 programas integrados que implementan utilidades típicas de UNIX 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 utilizar en el proceso.
Los datos en los mainframes de IBM normalmente residen en un sistema de archivos orientado a registros y los dispositivos de E/S conectados funcionan en modo de grabación en lugar de modo de transmisión. Como consecuencia, los datos en CMS Pipelines se manejan en modo de registro. Para archivos de texto, un registro contiene una línea de texto. En general, CMS Pipelines no almacena los datos en un buffer, sino que pasa registros de datos en forma gradual de un programa al siguiente. Esto garantiza un flujo determinista de datos a través de una red de tuberías interconectadas.
Además de las canalizaciones basadas en flujos de bytes, también existen canalizaciones de objetos. En una canalización de objetos, el procesamiento de elementos genera objetos en lugar de texto. PowerShell incluye una canalización de objetos interna que transfiere objetos .NET entre funciones dentro del tiempo 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 canalizaciones. En lugar de proporcionar un cuadro de diálogo para guardar que contiene 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 para guardar que contiene un icono (y un campo para especificar el nombre). El destino se especifica arrastrando y soltando el icono. El usuario puede colocar el ícono en cualquier lugar donde se pueda colocar un archivo ya guardado, incluso en íconos de otros programas. Si el ícono se coloca sobre el ícono 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 navega por Internet puede encontrar una imagen comprimida .gz que desee editar y volver a cargar. Usando canalizaciones GUI, podrían arrastrar el enlace a su programa de desarchivado, arrastrar el ícono que representa el contenido extraído a su editor de imágenes , editarlo, abrir el cuadro de diálogo Guardar como y arrastrar su ícono a su software de carga.
Conceptualmente, este método podría usarse con un cuadro de diálogo de guardar convencional, pero esto requeriría que los programas del usuario tuvieran una ubicación obvia y fácilmente accesible en el sistema de archivos a la que se pueda navegar. En la práctica, este no suele ser el caso, por lo que las canalizaciones de GUI son raras.
El nombre "tubería" proviene de una analogía aproximada con la plomería física en la que una tubería generalmente [1] 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 verse como una forma de programación funcional , utilizando flujos de bytes como objetos de datos; más específicamente, pueden verse como una forma particular de mónada para E/S . [2]
El concepto de canalización también es fundamental para el marco de desarrollo web Cocoon o para cualquier implementación de XProc (los estándares W3C), donde permite modificar un flujo fuente antes de su eventual visualización.
Este patrón fomenta el uso de flujos de texto como entrada y salida de programas. Esta dependencia del texto debe tenerse en cuenta al crear estructuras gráficas para programas de texto.