Doors es una herramienta de comunicación entre procesos para sistemas informáticos Unix . Proporciona una forma de llamada a un procedimiento .
Las puertas fueron desarrolladas por Sun Microsystems como parte central del sistema operativo Spring y luego se agregaron a Solaris en la versión 2.5 como una interfaz interna no documentada. [1] Se convirtieron en una característica documentada en Solaris 2.6. Las versiones recientes de Solaris usan Doors en muchos lugares, incluidos nscd(el demonio de caché del servicio de nombres ) y syslog .
En 2003 se lanzó una versión Linux de Doors, pero sólo está disponible para la versión 2.4.18. [2]
El subsistema Doors se implementa como una biblioteca de espacio de usuario con cierto soporte del núcleo y depende en gran medida de subprocesos . Está diseñado para una sobrecarga baja y la implementación de Solaris utiliza algo de código ensamblador para lograr la máxima eficiencia.
Las puertas son creadas por procesos de servidor (que deben usar subprocesos) y llamadas por procesos de cliente. Es posible que un proceso cree y llame a una puerta. Al crear una puerta, el servidor debe especificar un procedimiento de servidor, que será llamado por la biblioteca Doors en nombre de los clientes. A diferencia de la mayoría de los sistemas de llamadas a procedimientos remotos , cada puerta tiene solo un procedimiento de servidor. Un servidor puede "adjuntar" una puerta a un archivo, lo que permite a los clientes conectarse a esa puerta simplemente abriendo ese archivo. El ls -lcomando mostrará entonces el archivo con un "tipo" de "D" (que no debe confundirse con "d" para un directorio); por ejemplo:
$ ls -l total 9 Drw-r--r-- 1 jmorrison dev 876 8 de diciembre 19:43 miarchivoLos clientes suelen door_call()invocar el procedimiento del servidor de la puerta, pasando una región contigua de memoria y una lista de descriptores de archivos como argumentos, y obteniendo de vuelta otra región contigua y una lista de descriptores de archivos. Cualquier región puede estar vacía, al igual que cualquier lista. Por lo general, se definirán dos C , una para los datos de entrada y otra para los datos de salida. (Alternativamente, se pueden utilizar uniones etiquetadas , lo que permite que un procedimiento de puerta proporcione múltiples acciones de la misma manera que la llamada al sistema ioctl ). Cada descriptor de archivo está acompañado por una palabra de indicadores. El indicador solicita que se cierre un descriptor de archivo en el proceso de envío después de ser duplicado en el proceso de recepción. Si se envía un descriptor de archivo que hace referencia a una puerta, el sistema registra las propiedades de esa puerta en la palabra de indicadores.structDOOR_RELEASE
Además de representar un procedimiento o un grupo de procedimientos, una puerta puede representar un objeto de datos con estado , lo que permite pasar referencias a dichos objetos entre procesos. Una puerta de este tipo normalmente tomaría una unión etiquetada como datos de entrada, y cada valor de etiqueta denotaría un método diferente .
El sistema Doors también ofrece una forma para que los clientes y servidores obtengan información entre sí. Por ejemplo, un servidor puede verificar el ID de usuario o proceso del cliente para implementar el control de acceso .
La biblioteca Doors normalmente crea y administra un grupo de subprocesos en el proceso del servidor para manejar las llamadas, pero es posible anular este comportamiento. El sistema Doors no proporciona ninguna forma de sincronización, pero los servidores pueden usar las primitivas de sincronización a nivel de subproceso normales. Doors se puede usar para sincronizar el acceso a segmentos de memoria compartida , lo que permite la transferencia de datos de una sola copia. [3]
El concepto de Doors es muy similar a la especificación API X/Open XATMI, donde los procesos cliente invocan las funciones expuestas de los procesos del servidor: door_call()es análogo a tpcall()en los clientes XATMI, mientras que door_return()es análogo a tpreturn()en los servidores XATMI.