CAUCES

Otra manera de intercambiar información son los cauces (pipes). En OS/2 existen dos tipos: con nombre (named pipes) y sin nombre (unnamed pipes).

Los cauces son vistos por el programador como un fichero más, en el que, o bien puede leer, o bien escribir. La cuestión es que un extremo pertenece a un thread y el otro a otro distinto, y si uno de ellos escribe en ese fichero (recordemos que el sistema de archivos de OS/2, al igual que el de cualquier otro S.O., consigue que no sepamos diferenciar cuando trabajamos con un fichero de disco, con un cauce, o con la pantalla), cuando el otro lea, encontrará los datos grabados. Podríamos definirlo como una tubería (la cual es otra de las traducciones que he encontrado en algunos libros) que conecta los dos threads, y que se maneja con las mismas ordenes que el sistema de ficheros: DosRead, DosWrite y DosClose.

Cuando creamos una unnamed pipe, el sistema nos devuelve dos handles o indicativos: uno para lectura y otro para escritura. El thread que creó el cauce debe quedarse con uno, y enviar el otro al otro thread. Para ello puede usar un pequeño bloque de memoria compartida, definiendo claramente como acceder a ella. Dado que los demás threads van a acceder solo en lectura, no haría falta incluir un semáforo.

Los cauces tienen una opción muy interesante (y útil), que consiste en la posibilidad de duplicar handles. Usando la llamada DosDupHandle, se pueden crear dos handles para un mismo cauce. Lo interesante es que se puede dar no solo el siguiente número libre, sino el que se quiera. Haciendo esto, se puede asignar a un cauce el valor 0 y a otro el 1, y redirigir así la entrada y salida estandar (STDIN y STDOUT) del programa en curso. Esto es precisamente lo que hace el interprete de comandos de OS/2 para hacer la redirección desde la línea de comandos.

DosCreatePipe
DosDupHandle

En las versiones 1.x de OS/2 solo existian estos cauces; sin embargo, su potencia quedaba ligeramente oscurecida por el hecho de tener que usar memoria compartida para pasar un handle al otro thread. Para evitarlo, se añadieron en OS/2 2.0 y superiores las named pipes, o cauces con nombre (denominación horrible a mas no poder. Espero sugerencias para una posible traducción). En estos, al crearlos se les asigna un nombre del tipo \PIPE\un_nombre. Dentro de un_nombre puede ir cualquier cadena. Ejemplos válidos son \PIPE\EJEMPLO, \PIPE\CURSO\OS2\EJEMPLO_DE_PIPE. Cuando un thread cualquiera quiere acceder a ese cauce, solo tiene que referirse a él por dicho indicativo. Esto resulta mucho más cómodo, pues basta con fijar durante la programación el nombre que se le va a dar, y no hace falta pasarlo de forma dinámica en cada ejecución. Sin embargo, además de crearlo, es necesario que el proceso servidor lo haga disponible a los clientes.

DosCreateNPipe
DosConnectNPipe
DosDisConnectNPipe

Para que un cliente acceda a una named pipe, tiene que usar DosOpen, usando como nombre de fichero el nombre de la pipe. El segundo parámetro es un puntero a una variable de tipo HPIPE, que contendrá un handle que podremos usar con DosRead, DosWrite y DosClose para manejar la pipe. El tercer parámetro contendrá un puntero a un ULONG, en el cual se almacenará la causa por la que no se ha podido abrir la pipe (es mejor usar los códigos de error que se devuelven de la forma normal en vez de éste valor). El cuarto parámetro contiene la longitud del buffer que se reservará. Es conveniente que tenga un tamaño más bien grande. El resto de parámetros son particularizaciones para las pipes de los parámetro normales de DosOpen.

Se debe tener cuidado al definir las named pipes. Hay que tener en cuenta que el servidor tiene ciertos privilegios que el cliente no tiene, como por ejemplo disponer de un semáforo que le indique cuando hay datos en el cauce. Un cliente tendría que hacer una espera activa en el caso de querer estar siempre disponible a través de ese cauce. Por otro lado, cualquier cliente se puede conectar a una pipe, por lo que el servidor no puede saber (en principio) quien le está reclamando el servicio. Al revés sí ocurre, pues todo cliente sabe quien es el servidor de un cauce determinado por el nombre de éste.

DosSetNPipeSem
DosQueryNPHState
DosSetNPHState
DosWaitNPipe
DosPeekNPipe

Un detalle importante es que las unnamed pipes son unidireccionales. Esto es, si se quiere intercambiar datos en ambos sentidos, son necesarios dos cauces, no se puede usar el mismo. El sentido de la comunicación lo decide el que cree el cauce, al enviar uno u otro handle. En el caso de named pipes, por el contrario, el creador puede determinar si la comunicación va del servidor al cliente, al revés, o en ambos sentidos.

Pagina anterior  Indice  Pagina siguiente