The UNIX Time-Sharing System - D.M. Ritchie y K. Thompson

Traducción de las secciones V y VI por: M. Bordese y W. Alini 
Setiembre 2003 - Sistemas Operativos
FaMAF - UNC 

V. PROCESOS E IMÁGENES

Una imagen es un ambiente de ejecución de computadora. Incluye una imagen de memoria, valores de registros generales, estado de archivos abiertos, directorio actual y demás. Una imagen es el estado actual de una pseudo-computadora.

Un proceso es la ejecución de una imagen. Mientras el procesador está ejecutando un proceso, la imagen debe residir en la memoria principal; durante la ejecución de otros procesos permanece en la memoria principal hasta la aparición de un proceso activo y de prioridad más alta que lo fuerza a ser intercambiado al disco (swap).

La parte de memoria de usuario de una imagen está dividida en tres segmentos lógicos. El segmento de texto del programa empieza en la ubicación 0 del espacio virtual de direcciones. Durante la ejecución, este segmento está protegido contra escritura y una copia de él es compartida entre todos los procesos de ejecución del mismo programa. En el primer byte límite de protección de hardware por encima del segmento de texto del programa en el espacio virtual de direcciones empieza un espacio no compartido, con permiso de escritura cuyo tamaño puede ser extendido por una llamada de sistema. Empezando en la dirección más alta en el espacio virtual de direcciones hay un segmento de pila, el cual crece hacia abajo automáticamente mientras el stack pointer fluctúe.

5.1 Procesos

Excepto cuando el sistema se está autocargando para operar, un nuevo proceso sólo puede empezar a existir por el uso de la llamada a sistema fork:

	processid = fork ()

Cuando fork es ejecutado, el proceso se divide en dos procesos en
ejecución independientes. Los dos procesos tienen copias
independientes de la imagen de memoria original, y comparten todos los
archivos abiertos. Los nuevos procesos difieren sólo en que uno es
considerado el proceso padre: en el padre, el 'processid' devuelto en
realidad identifica al proceso hijo y nunca es 0, mientras que en el
hijo, el valor retornado es siempre 0.

Como los valores devueltos por fork para los procesos padre e hijo son
distinguibles, cada proceso puede determinar si es el padre o el hijo.

5.2 Tuberías (pipes)

Los procesos deben relacionarse con sus familiares usando las mismas llamadas a sistema 'read' y 'write' que son usadas por el sistema de archivos de entrada y salida. La llamada: 

	filep = pipe()

devuelve un file descriptor 'filep' y crea un canal de interprocesos
llamado pipe. Este canal, como otros archivos abiertos, es pasado de
procesos padres a hijos en la imagen por la llamada fork. Un 'read'
usando un pipe file descriptor espera hasta que otro proceso escriba
usando el file descriptor por el mismo pipe. En este punto, los datos
son pasados entre las imágenes de los dos procesos. Ninguno de los
procesos necesita saber que hay un pipe involucrado en vez de un
archivo común.

Si bien la comunicación interprocesos vía pipes es una herramienta muy valiosa (ver Sección 6.2), no es un mecanismo general completo, pues el pipe debe ser instaurado por un ancestro común de los procesos involucrados.

5.3 Ejecución de programas

Otra primitiva de sistema trascendental es invocada por

	execute(file, arg1, arg2, ... , argn)

la cual solicita al sistema leer y ejecutar el programa cuyo nombre es 'file', pasándole los argumentos 'arg1', 'arg2', ..., 'argn'. Todo el código y los datos en el proceso invocando 'execute' es reemplazado desde 'file', excepto archivos abiertos, directorio actual y relaciones interprocesos que permanecen inalterables. Sólo si la llamada falla, por ejemplo porque 'file' no pudo ser encontrado o porque su bit de permiso de ejecución no estaba habilitado, la primitiva 'execute' hace un return; se parece más a una instrucción de salto ("jump") que a una llamada a subrutina.

5.4 Sincronización de procesos

Otra llamada a sistema de control de procesos:

	processid = wait(status)

causa a quien lo llama suspender la ejecución hasta que uno de sus hijos complete la ejecución. Luego 'wait' devuelve el 'processid' del proceso terminado. Se devuelve error si el proceso que llama no tiene descendientes. También está disponible cierto estado del proceso hijo.

5.5 Terminación

Por último:

	exit(status)

termina un proceso, destruye su imagen, cierra sus archivos abiertos,
y generalmente lo hace desaparecer. El padre es informado mediante la
llamada 'wait', y se le deja disponible 'status'. Los procesos también
pueden terminar como resultado de varias acciones ilegales o señales
generadas por usuarios.

VI. EL INTÉRPRETE DE COMANDOS (SHELL)

Para la mayoría de usuarios, la comunicación con el sistema es llevada adelante gracias a la ayuda de un programa llamado shell. El shell es un intérprete de línea de comandos: lee líneas tipeadas por el usuario y las interpreta como pedidos de ejecución de otros programas. (El shell es descripto íntegramente en algún lado [9], con lo que en esta sección se discutirá sólo la teoría de su funcionamiento.) En un formato simple, una línea de comandos consiste en el nombre del comando seguido por argumentos al mismo, todo separado por espacios:

	command arg1 arg2 ... argn

El shell divide el nombre del comando y los argumentos en palabras separadas. Luego un archivo de nombre 'command' es buscado; 'command' puede ser el nombre de ruta incluyendo el caracter "/" para especificar cualquier archivo en el sistema. Si 'command' es encontrado, es llevado a la memoria y ejecutado. Los argumentos recogidos por el shell están accesibles para el comando. Cuando el comando hubo terminado, el shell reanuda su propia ejecución, e indica que está listo para aceptar otro comando mostrando el prompt.

Si el archivo 'comando' no pudo ser encontrado, el shell generalmente prefija una palabra como '/bin' a 'comando' e intenta encontrar el archivo de nuevo. El directorio '/bin' contiene comandos destinados a ser ejecutados generalmente. (La secuencia de directorios a ser buscados puede cambiar a pedido del usuario).


6.1 Entrada/Salida standard

La discusión de E/S citada anteriormente en la sección III parece implicar que cada archivo usado por un programa debe ser abierto o creado por el programa a fin de obtener un file descriptor del archivo. Los programas ejecutados por el shell, sin embargo, se ponen en marcha con tres archivos abiertos con los file descriptors 0, 1 y 2. Al empezar un programa su ejecución, el archivo 1 es abierto para escritura, y es más conocido como el archivo de salida estándar. Excepto por circunstancias indicadas más abajo, este archivo es la terminal de usuario. De esta manera, programas que quieran escribir información comúnmente usan el file descriptor 1. Inversamente, el archivo 0 se pone en marcha para lectura, y los programas que quieran leer mensajes tipeados por el usuario leen este archivo.

El shell es capaz de cambiar las asignaciones estándar de estos file descriptors que son la impresora de terminal y el teclado. Si uno de los argumentos de un comando es precedido por ">", el file descriptor 1 se referirá, a lo largo de la duración del comando, al archivo nombrado después del ">". Por ejemplo:

	ls

comúnmente lista los nombres de los archivos del directorio actual. El comando:

	ls >there

crea un archivo llamado 'there' y ubica el listado allí. Así, el argumento significa "ubica la salida en 'there'". Por otra parte:

	ed

comúnmente ingresa el editor, el cual toma pedidos del usuario via su teclado. El comando

	ed <script

interpreta 'script' como un archivo editor de comandos; así "<script" significa "toma la entrada desde 'script'".

Aunque el nombre de archivo seguido a "<" o ">" aparenta ser un argumento del comando, en realidad es interpretado completamente por el shell y no es pasado para nada al comando. De esta manera, no es necesario ningún código especial para manipular redirecciones de E/S con cada comando; el comando solamente necesita usar los file descriptors standard 0 y 1 adecuadamente.

El file descriptor 2 es, como el 1, comúnmente asociado con el flujo de salida de la terminal. Cuando un pedido de salida modificado con ">" es especificado, el archivo 2 permanece adherido a la terminal, así los comandos pueden producir mensajes de diagnóstico que no terminan silenciosamente en el archivo de salida.

6.2 Filtros

Una extensión del uso de la noción estándar de E/S es dirigir la salida de un comando como la entrada de otro. Una secuencia de comandos separados por barras verticales (pipes) hacen que el shell ejecute todos los comandos simultáneamente y adopte la salida estándar de cada comando como la entrada estándar del comando siguiente en la secuencia. Entonces en la línea siguiente:

	ls | pr -2 | opr

ls lista los nombres de los archivos en el directorio actual; su salida es pasada a pr, que pagina su entrada con encabezados fechados. (El argumento "-2" produce una salida a doble columna.) De la misma forma, la salida de pr pasará como entrada de opr; este comando spoolea su entrada en un archivo para su impresión off-line.

Este resultado podría haberse obtenido de forma más incómoda de la siguiente manera:

	ls >temp1
	pr -2 <temp1 >temp2
	opr <temp2

seguido por el borrado de los archivos temporales. En caso de no contar con la posibilidad de redirigir la entrada y la salida, un método todavía más engorroso sería necesario para paginar la salida del comando ls, imprimirla en un formato multi-columna, y arreglar que su salida sea enviada off-line. En realidad, sería sorprendente, y de hecho imprudente por razones de eficiencia, esperar que los autores  de comandos como ls provean tal amplia variedad de opciones de salida.

Un programa como pr que copia su entrada estándar a su salida estándar (con procesamiento) es llamado filtro. Algunos otros filtros útiles hacen transliteración de caracteres, selección de líneas de acuerdo a un patrón, ordenamiento de la entrada, y encriptamiento y desencriptamiento.

6.3 Separadores de comandos; multitarea

Otra característica provista por el shell es una relativa linealidad. Los comandos no necesitan estar en diferentes líneas; en lugar de esto, pueden estar separados por punto y coma:

	ls; ed

primero listará el contenido del directorio actual y luego ejecutará el editor.

Una característica relacionada es aún más interesante. Si un comando es seguido por "&", el shell no esperará que el comando finalice antes de mostrar nuevamente el prompt; en cambio, estará listo para aceptar un nuevo comando inmediatamente. Por ejemplo:

	as source >output &

hace que source sea ensamblado, y su diagnóstico de salida sea enviado a output; no importa que tanto tiempo lleve el ensamblado, el shell vuelve inmediatamente. Cuando el shell no espera que se complete la ejecución del comando, imprime el número de identificación del proceso correspondiente a dicho comando. Este identificador puede ser usado para esperar que se complete el mismo o terminarlo. El "&" puede ser usado varias veces en una línea:

	as source >output & ls >files &

ejecuta el ensamblado y el listado de archivos en segundo plano (background). En estos ejemplos, un archivo de salida es dado como salida estándar;  si no se hubiera hecho así, las salidas de los comandos se entremezclarían.

El shell también permite el uso de paréntesis en las operaciones de arriba. Por ejemplo:

	(date; ls) >x &

escribe la fecha y hora actuales seguidas por el listado del directorio actual en el archivo x. El shell también vuelve inmediatamente a la espera de un nuevo pedido.

6.4 El shell como un comando; archivos de comandos

El shell es en sí mismo un comando, y puede ser llamado recursivamente. Supongamos que un archivo de prueba contiene las líneas:

	as source
	mv a.out testprog
	testprog

El comando mv hace que el archivo a.out sea renombrado como testprog. a.out es la salida (binaria) del ensamblador, lista para ser ejecutada. Entonces si las tres líneas de arriba fueran tipeadas con el teclado, source sería ensamblado, el programa resultante sería renombrado a testprog, y testprog sería ejecutado. Como las líneas están en tryout, el comando:

	sh <tryout

haría que el shell sh ejecutara los comandos secuencialmente.

El shell tiene capacidades más amplias, incluso de sustituir parámetros y construir listas de argumentos a partir de un conjunto específico de nombres de archivos en un directorio. También provee construcciones condicionales y de loop.

6.5 Implementación del shell

Una reseña sobre el funcionamiento del shell puede ahora ser entendida. La mayor parte del tiempo, el shell está esperando que el usuario tipee un comando. Cuando el caracter de nueva línea finaliza la línea tipeada, se produce una llamada de lectura del shell. El shell analiza la línea de comandos, poniendo los argumentos en una forma apropiada para la ejecución. Luego se llama a fork. El proceso hijo, cuyo código por supuesto es todavía el del shell, intenta efectuar una ejecución con los argumentos apropiados. Si tiene éxito, se comenzará la ejecución del programa cuyo nombre fue dado. Mientras tanto, el otro proceso resultante del fork, el proceso padre, espera que el proceso hijo muera. Cuando esto sucede, el shell sabe que el comando finalizó, entonces muestra el prompt y lee la entrada del teclado para obtener otro comando.

Dado este marco de funcionamiento, la implementación de procesos en background es trivial; siempre que una línea de comando contiene "&", el shell se abstiene de esperar que el proceso creado ejecute el comando.

Felizmente, todo este mecanismo se lleva muy bien con la noción de entrada y salida estándar a archivos. Cuando un proceso es creado por la primitiva fork, éste hereda no sólo la imagen de memoria de su padre sino también todos los archivos abiertos al momento en su padre, incluyendo aquellos con file descriptors 0, 1 y 2. El shell, por supuesto, usa estos archivos para leer la línea de comandos y escribir su prompt y diagnósticos, y en general su hijo - programa - los hereda automáticamente. Cuando se da un argumento con "<" o ">", sin embargo, el proceso hijo, justo antes de efectuar la ejecución, hace que los file descriptors de la  E/S estándar (0 ó 1, respectivamente) apunten al archivo dado. Esto es fácil porque, por convención, el menor file descriptor sin usar es asignado cuando un nuevo archivo es abierto (o creado); sólo es necesario cerrar el archivo 0 (ó 1) y abrir el archivo dado. Cuando el proceso en el cual se ejecuta el programa termina, la asociación entre el archivo especificado después de "<" o ">" y el file descriptor 0 ó 1 finaliza automáticamente cuando el proceso muere. Entonces el shell no necesita saber los nombres de los archivos que son su entrada y salida estándar, porque nunca necesita reabrirlos.

Los filtros son extensiones de redirección de E/S estándar usados con pipes en lugar de archivos.

En circunstancias ordinarias, el loop principal del shell nunca termina. (El loop principal incluye la rama de retorno desde el fork perteneciente al proceso padre; i.e., la rama que espera, luego lee otra línea de comandos.) Lo único que produce que el shell termine es encontrar una condición de end-of-file(EOF) en su archivo de entrada. Entonces, cuando el shell es ejecutado como un comando con un archivo de entrada dado, como en:
	
	sh <comfile

los comandos en comfile son ejecutados hasta que se alcanza el fin de comfile; entonces la instancia del shell invocada por sh terminará.  Como este proceso shell es hijo de otra instancia del shell, la espera que se produce en esta última nos devolverá luego el prompt y entonces podremos procesar otro comando.

6.6 Inicialización

Las instancias del shell en las que los usuarios tipean comandos son hijas de otro proceso. El último paso en la inicialización del sistema es la creación de un proceso y la invocación (via execute) de un programa llamado init. El rol de init consiste en crear un proceso para cada canal terminal. Las varias subinstancias de init abren las terminales apropiadas para entrada y salida en 0, 1 y 2, esperando, si es necesario, que el cargador sea establecido por líneas dial-up. Entonces un mensaje aparece solicitando el log-in de usuario. Cuando el usuario tipea un nombre u otra identificación, la instancia apropiada de init se despierta, recibe la línea de log-in, y lee el archivo de password. Si se encuentra el nombre de usuario, y éste da el password correcto, init cambia al directorio por defecto del usuario, setea el ID de usuario de proceso al de la persona logeada, y ejecuta el shell. En este punto, el shell está listo para recibir comandos y el protocolo de logging-in está completado.

Mientras, el flujo principal de init (padre de todas las subinstancias de sí mismo que más tarde serán shells) hace una espera. Si uno de los procesos hijo termina, ya sea porque un shell encontró un EOF o porque un usuario tipeó un nombre o password incorrecto, este flujo de init simplemente recrea el proceso difunto, el cual en consecuencia reabre los archivos de entrada y salida apropiados y muestra otro mensaje de log-in. Entonces un usuario puede hacer un log-out simplemente tipeando la secuencia de end-of-file en el shell.

6.7 Otros programas como shell

El shell como se ha descrito arriba está diseñado para permitir a los usuarios un acceso total a las facilidades del sistema, porque éste invocará la ejecución de cualquier programa con el modo de protección apropiado. Algunas veces, sin embargo, se desea una interfase de sistema diferente, y esta posibilidad es fácilmente arreglada.

Recordemos que después que el usuario se logeado éxitosamente dando su nombre y password, init ordinariamente invoca el shell para interpretar líneas de comando. La entrada del usuario en el archivo de password puede contener el nombre de un programa para ser invocado en lugar del shell después del log-in. Este programa es libre de interpretar los mensajes del usuario de la manera que desee.

Por ejemplo, las entradas del archivo de password para los usuarios de un sistema de edición secretarial podrían especificar que el editor ed sea usado en lugar del shell. Entonces cuando los usuarios del sistema de edición se logean, entran en el editor y pueden empezar a trabajar inmediatamente; también, puede evitarse que invoquen programas  no destinados para su uso. En la práctica, ha sido demostrado deseable permitir un escape temporario del editor para ejecutar el programa de formato y otras utilidades.

Varios de los juegos (ej.: chess, blackjack, 3D tic-tac-toe) disponibles en el sistema ilustran un entorno mucho más restringido. Para cada uno de estos, existe una entrada en el archivo de password que especifica que el juego correspondiente será invocado en lugar del shell. La gente que se logea como jugador de uno de estos juegos se ven limitados al juego e imposibilitados de investigar las (presumiblemente más interesantes) ofertas del sistema Unix como un todo.