2 Programas y procesos

Transcripción

1 2 Programas y procesos 2.1. Procesos Un programa en ejecución es un proceso. El nombre programa no se utiliza para referirse a un programa en ejecución, porque ambos conceptos son distintos. La diferencia es la misma que la que puede haber entre una galleta y la receta para hacer galletas. Un programa es un montón de datos, no es nada que esté vivo. Al contrario, un proceso es algo vivo, dinámico, que está haciendo cosas (ejecutando). Un proceso tiene un conjunto de registros que está usando, tiene un contador de programa que indica la siguiente instrucción que debe ejecutar, y tiene una pila. Esto significa que tiene un flujo de control que ejecuta una instrucción tras otra, como ya sabemos. La diferencia queda bastante clara si se considera que puedes ejecutar simultáneamente el mismo programa varias veces. Por ejemplo, la figura 2.1 muestra el sistema de ventanas con tres ventanas. Cada una de ellas ejecuta un shell. Por tanto tenemos tres procesos ejecutando el programa /bin/rc, aunque sólo hay un programa para estos procesos, que está almacenado en un fichero llamado /bin/rc. Más aun, si cambiamos el directorio de trabajo en un shell, los otros shells no se ven afectados Pruébalo! Supongamos que el programa rc guarda en una variable su directorio de trabajo. Cada proceso que ejecuta el shell tiene su propia variable para el directorio de trabajo. Sin embargo, el programa únicamente tiene una variable declarada con ese propósito. Figura 2.1: Tres procesos /bin/rc, pero sólo un programa /bin/rc. Entonces, Qué es un proceso? Consideremos todos los programas que hemos hecho. Escojamos cualquiera de ellos. Cuando ejecutamos un programa y se arranca un proceso, puede ejecutar independientemente de los demás programas del sistema. O acaso hemos tenido en cuenta al reloj del sistema, al shell, al navegador, o a cualquier otro programa para programar nuestros propios programas? No. Necesitaríamos tener mucha memoria para poder tener en cuenta todo esto a la hora de escribir un programa. Los sistemas operativos nos dan la abstracción de proceso para no tener en cuenta al resto de programas que están ejecutando, para olvidarnos de ellos. Cada proceso tiene la ilusión de que tiene su propio procesador. Cuando escribimos un programa, siempre pensamos que se ejecutan las instrucciones una detrás de otra. Pero siempre pensamos en las instrucciones de nuestro proceso, no en las de los demás. La implementación de la

2 - 2 - abstracción llamada proceso en el sistema operativo es la que nos ofrece esta fantasía. Cuando una máquina tiene varios procesadores, se pueden ejecutar múltiples programas en paralelo, esto es, al mismo tiempo. Aunque esto es común en la actualidad, todavía hay máquinas con un único procesador. En ocasiones nos encontramos con máquinas que tienen dos o cuatro procesadores. Pero la cuestión es que ejecutas más programas que procesadores tiene tu máquina. Cuenta el número de ventanas en tu terminal. Cada una ejecuta al menos un programa. Está claro que tu ordenador no tienen tantos procesadores. Lo que ocurre es que el sistema operativo se las apaña para dejar ejecutar a cada programa en ejecución un tiempo limitado. La figura 2.2 muestra la memoria de un sistema con tres procesos ejecutando. Cada proceso tiene su conjunto de registros, que incluyen un contador de programa. Esta figura es sólo una instantánea tomada en momento dado. En un instante, el sistema puede permitir al proceso 1 (que ejecuta rio) que proceda y ejecute su código. Después, el timer hardware que ha puesto el sistema salta, y avisa al sistema de que el tiempo para este proceso ha terminado. En este punto, el sistema puede saltar al proceso 2, que está ejecutando rc. Cuando el tiempo para el proceso 2 termina, el sistema puede saltar al proceso 3 que ejecuta rio. Cuando su tiempo acabe, se podrá saltar al proceso 1 de nuevo, y retomarlo donde se había quedado. PC... addl bx, di addl bx, si subl $4, di movl bx, cx... Rio (proceso #1) PC... cmpl si, di jls label movl bx, cx addl bx, si... Rio (proceso #3)... addl bx, di PC addl bx, si subl $4, di movl bx, cx... Rc (proceso #2) Memoria del Sistema Figura 2.2: Ejecución concurrente de varios procesos en el mismo sistema. Todo lo que hemos contado ocurre entre bastidores. El sistema operativo sabe que sólo hay un flujo de control por procesador, y salta de un proceso a otro para transferir el control. Para el usuario del sistema, todo lo que importa es que cada proceso ejecuta independientemente del resto, como si tuviese su propio procesador. Decimos que son procesos concurrentes, porque parece que ejecutan simultáneamente. En algunos casos, realmente ejecutan en paralelo (cuando tenemos más de un procesador). En la mayoría de los casos, estaremos hablando de una ejecución pseudo-paralela. Realmente, esto no es importante para el programador. Él tan sólo ve procesos concurrentes que parecen ejecutar simultáneamente.

3 - 3 - En este capítulo estudiaremos los procesos que obtenemos al ejecutar nuestros programas. Antes de nada, es importante saber lo que hay dentro de un programa y dentro de un proceso Programas cargados Cuando se compila un código fuente y se enlaza, se genera un fichero binario. Este fichero contiene toda la información necesaria para que ejecute el programa, esto es, para crear un proceso con el fin de ejecutarlo. Dentro del binario, la información se organiza en diferentes secciones. Un fichero binario comienza con unas palabras que describen las secciones que contiene. Estas palabras iniciales se denominan cabecera, y usualmente indica la arquitectura para la que son las instrucciones del binario y el tamaño y el offset (distancia) de cada una de las secciones. Una de las secciones del fichero contiene el texto del programa, que es el conjunto de instrucciones máquina. En otra sección distinta se almacenan e inicializan las variables globales del programa. Hay que tener en cuenta que el programa no sabe nada sobre el significado de esas variables, son sólo datos. Para las variables globales no inicializadas, únicamente se indica el tamaño total, ya que como no tiene un valor inicial, es absurdo reservar espacio en el fichero. Normalmente también se incluye información para ayudar al depurador, como cadenas de caracteres con el nombre de los símbolos y sus direcciones. En el último capítulo vimos cómo podemos usar nm para imprimir información acerca de los símbolos de los ficheros objeto y los binarios. Es importante remarcar que únicamente nuestro programa sabe el significado de los bytes de los datos del programa, esto es, de las variables. Para el sistema, los datos de nuestro programa no significan absolutamente nada. El sistema no sabe nada sobre nuestro programa (en realidad, nadie sabe nada excepto nosotros mismos). La información que muestra nm se obtiene de la tabla de símbolos que se incluye en el binario para ayudar en la depuración. Podemos eliminar la tabla de símbolos de un binario. Por ejemplo, podemos borrarlo del binario que generamos para el programa take.c. El comando strip sirve para esto. Para ver el tamaño del binario, podemos usar la opción -l del comando ls, que como ya sabemos, lista la información de los ficheros, incluido el tamaño: ls -l 8.take --rwxr-xr-x M 19 nemo nemo Jul strip 8.take ls -l 8.take --rwxr-xr-x M 19 nemo nemo Jul 6 22:49 8.take 6 22:49 8.take El número que se encuentra antes de la fecha de modificación es el tamaño en bytes del fichero. El fichero ha pasado de tener bytes a tener bytes. La diferencia es el tamaño de la tabla de símbolos. Después de eliminarla, mn no nos puede decir nada acerca de los símbolos del binario. Ahora, sabe lo mismo que el sistema: nada. nm 8.take El sistema sigue un convenio para saber la dirección en la que se debe comenzar a ejecutar el programa. Sin embargo, no le importa lo que hace el código que se encuentra allí. Un programa almacenado en un fichero es distinto que el mismo programa cuando ha sido cargado en memoria para ejecutarse. Están relacionados, pero no son iguales. Consideremos el siguiente programa, que no hace mucho, pero tiene una variable global de 1 MByte:

4 - 4 - global.c #include <u.h> #include <libc.h> char global[1 * 1024 * 1024] void main(int, char*[]) { exits(nil) Asumiendo que el programa se llama global.c, podemos compilarlo y enlazarlo con la opción -o del enlazador para especificar que el binario se llame 8.global. Es una buena práctica nombrar el fichero binario según el nombre del programa, especialmente cuando hay múltiples programas en el mismo directorio: 8c -FVw global.c 8l -o 8.global global.8 ls -l 8.global global.8 --rwxr-xr-x M 19 nemo nemo 3380 Jul 6 23:06 8.global --rw-r--r-- M 19 nemo nemo 328 Jul 6 23:06 global.8 Está claro que no hay espacio en los 328 bytes para la variable global del programa, que necesita 1 MByte de almacenamiento. La explicación es que únicamente se almacena en el binario que hay una variable global, pero no su contenido. Podemos cambiar el tamaño del array, por ejemplo a 2 MByte, y veremos que el tamaño del binario no cambia. Cuando el shell pide al sistema (mediante una llamada al sistema) que ejecute el binario 8.global, el sistema carga el programa en memoria. La parte del núcleo del sistema que realiza esta operación se denomina cargador o loader Cómo puede cargar el sistema un programa? Lo hace leyendo la información del binario: La cabecera del binario indica la memoria necesaria para albergar el texto del programa, y en el binario tenemos una imagen del texto. Entonces, el sistema únicamente carga en una zona de la memoria el texto del binario. Hay convenciones para cada arquitectura que indican las direcciones se deben usar. Por tanto, el sistema sabe dónde tiene que cargar la imagen del texto. La cabecera también indica el tamaño de las variables globales que han sido inicializadas, y el fichero tiene también una imagen con los datos. El sistema carga esa imagen en otra zona de memoria. Hay que tener en cuenta que el sistema no sabe dónde empieza una variable ni cuál es su tamaño. El sistema sólo sabe el número de bytes que tiene la imagen y la dirección donde tiene que copiarla. Para las variables globales no inicializadas, la cabecera del binario sólo indica el tamaño total. El sistema reserva esa cantidad de memoria para nuestro programa. Es lo único que tiene que hacer. Por cortesía, Plan 9 inicializa toda esa memoria con todos los bytes a cero. Esto significa que todas las variables globales sin inicializar están inicializadas a valores nulos por omisión. Esto está muy bien, ya que los programas se pueden comportar mal si las variables no están correctamente inicializadas, y un valor nulo parece un buen valor por omisión verdad? Ahora veremos como nm imprime las direcciones para los símbolos. Estas direcciones son direcciones de memoria que sólo tienen sentido cuando el programa se ha cargado en memoria. De hecho, el manual de Plan 9 se refiere al enlazador como cargador. Esas direcciones son virtuales

5 - 5 - porque el sistema usa el hardware de memoria virtual para mantener a cada proceso en su espacio de direcciones. Aunque sean direcciones virtuales, las direcciones son absolutas, no son relativas (offsets) a un punto de origen. Usando nm podemos aprender más sobre el aspecto de un programa cargado. La opción -n hace que nm ordene su salida por dirección: nm -n 8.global 1020 T main 1033 T _main 1073 T atexit 10e2 T atexitdont 1124 T exits 1180 T _exits 1188 T getpid 11fb T memset 122a T lock 12e7 T canlock 130a T unlock 1315 T atol 1442 T atoi 1455 T sleep 145d T open 1465 T close 146d T read 14a0 T _tas 14ac T pread 14b4 T etext 2000 D argv D _tos 2008 D _nprivates 200c d onexlock 2010 D _privates 2014 d _exits 2024 B edata 2024 B onex 212c B global 10212c B end La figura 2.3 muestra la organización en memoria del programa cuando se carga. Observando la salida de nm podemos deducir varias cosas. Primero, el código del programa (texto) usa direcciones entre la 0x1020 y la 0x14b4. El último símbolo, etext, es un símbolo definido por el enlazador con el fin de marcar el final del texto. Los datos están entre la 0x2000 y la 0x10212c. También hay un símbolo llamado end, también definido por el enlazador, que marca el final de los datos. No hay que confundir este símbolo con edata, que indica el final de los datos inicializados. En decimal, la dirección de end es bytes. Eso es más que 1 MByte, que es mucha más memoria que los 3 KBytes que ocupa el fichero binario Puedes ver la diferencia? Todavía podemos observar más cosas. No hemos tenido en cuenta la pila del programa. Como ya sabrás, los programas necesitan una pila para ejecutar. La pila es la zona de memoria donde se almacenan los datos necesarios para para realizar llamadas a procedimiento, saber la dirección a la que hay que retornar y almacenar los parámetros y las variables locales. Por tanto, el tamaño del programa una vez cargado en memoria va a ser aun mayor. Para saber la cantidad de memoria que va a consumir un binario cuando sea cargado, no usamos ls, sino que usamos mn. La memoria del programa cargado, por tanto del proceso, se organiza como muestra la figura 2.3. Pero esto es únicamente una invención del sistema operativo. Es una abstracción que nos ofrece el sistema para hacernos la vida más fácil, implementada usando el hardware de

6 - 6 - Segmento Text Segmento Data Segmento BSS Segmento Stack Texto del programa Datos inicializados Datos no inicializados... Pila 0x0 etext edata end Figura 2.3: Imagen de la memoria del programa global. memoria virtual. Esta abstracción se denomina memoria virtual. Cada proceso cree que es el único programa cargado en memoria. Esto se puede observar en las direcciones que nos muestra el comando nm. Todos los procesos que ejecuten este programa tendrán las mismas direcciones, que son absolutas, y además podrán ejecutar al mismo tiempo en la mismo ordenador. La memoria virtual de un proceso en Plan 9 tiene varios segmentos. Esto también es una abstracción del sistema que no tienen nada que ver con la segmentación de hardware que se puede encontrar en los procesadores modernos. Un segmento de memoria es una porción de memoria contigua con alguna propiedad. Los segmentos de un proceso de Plan 9 son: El segmento de texto. Contiene las instrucciones del programa, que pueden ser ejecutadas pero no pueden ser modificadas. El sistema, junto con el hardware, asegura estas restricciones. El segmento se inicializa con la imagen de texto del fichero binario. El segmento de datos. Contiene los datos inicializados del programa. El contenido del segmento se puede leer y escribir. Sin embargo, su contenido no se puede ejecutar. El contenido se inicializa con los datos que están almacenados en el fichero binario. El segmento de datos no inicializados, denominado segmento BSS. Es similar al segmento de datos, pero todo su contenido se inicializa a cero. El nombre del segmento viene de una instrucción de una máquina muy antigua que ya no se usa. Este segmento tiene inicialmente el tamaño que se indica en la cabecera del fichero binario. Sin embargo, puede crecer mediante una llamada al sistema. Cada vez que se llama a malloc(2), se consume memoria de este segmento. Por tanto, cuando el segmento se queda sin espacio, se le pide al sistema que lo haga crecer. Esa es la razón por la que hay un hueco entre este segmento y el segmento de pila, para que pueda crecer. El segmento de pila. El segmento se puede leer y escribir, pero no ejecutar. Este segmento crece automáticamente cuando necesita más espacio, no como el resto de segmentos. Se usa para mantener la pila del proceso. Todo esto es importante y tiene un gran impacto en el comportamiento de nuestros programas. Normalmente, no se carga todo el código al segmento de texto desde fichero binario de una vez, sino que se va cargando a medida que se va necesitando. Los binarios se copian en memoria de página de memoria en página de memoria a medida que se referencian las direcciones de memoria. A esto se le llama paginación en demanda o carga en demanda. Es importante saber esto porque, si borramos un binario del sistema de ficheros mientras que un proceso lo está ejecutando, éste programa fallará y se quedará roto cuando necesite leer una página y el fichero ya no exista. Lo mismo pasará cuando reemplacemos el binario por otra versión mientras hay algún proceso ejecutándolo. Ya que la memoria es virtual y sólo se reserva cuando se usa por primera vez, cualquier parte que no se haya usado del segmento BSS está libre. No se consume la memoria hasta que no se toca por primera vez. No obstante, si inicializamos la memoria con un bucle, recorriendo todas las posiciones del array asignándolas un valor, toda la memoria queda reservada. Podemos sacar

7 - 7 - partido de los datos no inicializados, por ejemplo, al programar grandes tablas hash que contengan pocos elementos (sparse). Se pueden implementar con arrays grandes que no estén inicializados, cuya memoria física no se reservará al iniciar el programa. Cuando se necesite usar la tabla, el sistema reservará la memoria y la inicializará a cero, haciendo que todas las entradas sean valores nulos. En este ejemplo, la inicialización manual de la memoria tendría un gran impacto sobre el uso de la memoria (se reservaría toda esa memoria física desde el primer momento) Nacimiento y muerte de los procesos Los programas se ejecutan, no se llaman. De hecho, los programas nunca retornan, sino que su proceso acaba cuando desea o cuando tiene un comportamiento incorrecto. Aunque no se les llame, podemos pasar argumentos a un programa para controlar su comportamiento. Cuando el shell pide la ejecución de un programa, el sistema lo carga en la memoria y le asigna un flujo de control o flujo de ejecución. Entonces, se inicializan los valores necesarios para los registros del procesador del nuevo proceso, incluido el contador de programa y el puntero de pila, que apuntará a una pila nueva (y casi vacía). Cuando compilamos un programa de C, el cargador pone main a la dirección donde el se empezará a ejecutar el código del programa. De esta forma, nuestro programa comienza ejecutando main. Los argumentos proporcionados a un programa (por ejemplo, cuando ejecutamos un comando con opciones en el shell) se copian a la pila del nuevo programa. Los argumentos que se pasan a la función main del programa son un array de cadenas de caracteres (el vector de argumentos, argv) y un entero, que indica el número de elementos en el array. Implementemos un programa que imprima sus argumentos. echo.c #include <u.h> #include <libc.h> void main(int argc, char* argv[]) { int i for (i = 0 i < argc i++) print("%d: %s\n ", i, argv[i]) exits(nil) Si ejecutamos este programa, podremos ver los argumentos que se le pasan al programa desde la línea de comandos: 8c -FVw echo.c 8l -o 8.echo echo.8./8.echo one little program 0:./8.echo 1: one 2: little 3: program Hay varias cosas que remarcar en el programa. Primero, el primer argumento que se le ha proporcionado al programa es El nombre del programa! Específicamente, es el nombre como se le ha pasado al shell. Segundo, hemos dado una ruta relativa como nombre del comando. Recuerda que

8 - 8 -./8.echo se refiere al fichero 8.echo en el directorio de trabajo del shell. Por tanto, ese el valor de argv[0] en nuestro programa. Viendo el valor de argv[0], los programas pueden conocer su propio nombre. Esto es bastante útil para imprimir mensajes de diagnóstico que permitan al usuario identificar el programa que está teniendo los errores. Hay un comando estándar de Plan 9 que hace (casi) lo mismo que el programa que hemos escrito antes. Ese comando es echo. El comando echo imprime sus argumentos separándolos con un espacio, y acabando con un carácter de nueva línea. El carácter de nueva línea se puede omitir con la opción -n. echo hi there hi there echo -n hi there hi there Fíjate en el prompt del shell justo después de la salida de echo. Aunque este comando es simple, es muy útil, por ejemplo para generar cadenas de texto o para saber cuantos argumentos recibiría un comando. El programa que hemos hecho antes no es un echo perfecto. Como poco, el echo estándar puede recibir una opción -n para pedirle que sólo imprima sus argumentos (que no incluya la nueva línea). Vamos a añadir dos opciones a nuestro programa. La opción -n omitirá la nueva línea, y la opción -v imprimirá corchetes alrededor de cada argumento, para que podamos ver el comienzo y el final de cada uno de ellos. Si no se le pasa ninguna opción, el programa funcionará como la herramienta estándar, imprimiendo un argumento detrás de otro y con una nueva línea. En realidad, la única dificultad reside en controlar que el usuario pueda ejecutar el programa proporcionando los argumentos en distinto orden: 8.echo repeat after me 8.echo -n repeat after me 8.echo -v repeat after me 8.echo -n -v repeat after me 8.echo -nv repeat after me Es necesario que las opciones se puedan combinar de cualquiera de estas formas. Además, el usuario debe ser capaz de imprimir con echo argumentos como -word-, y el programa no debe confundir este argumento con una opción porque empiece por un guión. Por lo general, se usan dos guiones seguidos para indicar que no se van a proporcionar más opciones al programa y que todo lo que sigue son sólo argumentos: 8.echo -- -word-- Es un poco molesto procesar argv y argc a mano Verdad? Por esa razón, el sistema nos proporciona unas macros de C para ayudarnos a procesarlos. Las macros de C son definiciones que procesa el preprocesador de C antes de compilar, que reemplaza el nombre de la macro por su contenido. El siguiente programa es un ejemplo.

9 - 9 - aecho.c #include <u.h> #include <libc.h> void main(int argc, char* argv[]) { int nflag = 0 int vflag = 0 int i ARGBEGIN{ case v : vflag = 1 break case n : nflag = 1 break default: fprint(2, "usage: %s [-nv] args\n", argv0) exits("usage") ARGEND for (i = 0 i < argc i++) if (vflag) print("[%s] ", argv[i]) else print("%s ", argv[i]) if (!nflag) print("\n") exits(nil) Las macros ARGBEGIN y ARGEND iteran sobre el vector de argumentos, eliminando y procesando las opciones. Después de ARGEND, tanto argc como argv reflejan el vector de argumentos sin ninguna opción. Entre las dos macros debemos escribir el cuerpo de una estructura de control switch de C (que proporciona la macro ARGBEGIN), con un case por cada opción. Las macros tienen en cuenta las posibles combinaciones de las opciones. Probemos varias combinaciones a la hora de ejecutar el programa ahora:

10 aecho repeat after me repeat after me 8.aecho -v repeat after me [repeat] [after] [me] 8.aecho -vn repeat after me [repeat] [after] [me] 8.aecho -d repeat after me usage: 8.aecho [-nv] args 8.aecho -- -d repeat after me -d repeat after me we gave a return here. En todos los casos menos en el último, argc es 3 después de ARGEND, y argv tiene las siguientes cadenas: repeat, after, y me. Otra ventaja de usar las macros es que inicializan una variable global llamada argv0 para apuntar al argv[0] original en main, que apunta al nombre del programa. Usamos esa variable para imprimir errores de diagnóstico que indican la forma de uso del programa, que es lo que hay que hacer cuando alguien ejecuta el programa de forma incorrecta. En algunos casos, una opción puede tener un argumento. Por ejemplo, podemos hacer que el usuario pueda personalizar el carácter que indica el principio y el final de cada argumento en nuestro programa, esto es, reemplazar [ y ] por otros caracteres cuando está usando la opción -v. Esto se puede hacer añadiendo una opción -d. Por ejemplo: 8.aecho -v -d"" repeat after me Esto se puede implementar usando otra macro llamada ARGF. Esta macro se usa dentro del case para una opción, y retorna un puntero al argumento de la opción (al argumento, o al siguiente modificador si no se ha dado argumento, o nil si no hay nada en el vector de argumentos después de la opción que se está procesando). El programa resultante es el que sigue. becho.c #include <u.h> #include <libc.h> void usage(void) { fprint(2, "usage: %s [-nv] [-d delims] args\n", argv0) exits("usage") void main(int argc, char* argv[]) { int nflag = 0 int vflag = 0 char* delims = "[]" int i

11 ARGBEGIN{ case v : vflag = 1 break case n : nflag = 1 break case d : delims = ARGF() if (delims == nil strlen(delims) < 2) usage() break default: usage() ARGEND for (i = 0 i < argc i++) if (vflag) print("%c%s%c ", delims[0], argv[i], delims[1]) else print("%s ", argv[i]) if (!nflag) print("\n") exits(nil) A continuación se muestran varios ejemplos de uso de nuestro programa: 8.becho -v -d"" repeat after me "repeat" "after" "me" 8.becho -vd "" repeat after me note the space before the "" "repeat" "after" "me" 8.becho -v 8.becho -v -d usage: 8.becho [-nv] [-d delims] args Si falta un argumento para una opción, normalmente se termina el programa mostrando el modo de uso (llamando a una función usage). La macro EARGF se usa en lugar de ARGF con ese fin (llamar a una función en caso de que no haya argumento para la opción). Podemos cambiar nuestro código para que use esta macro: case d : delims = EARGF(usage()) if (strlen(delims) < 2) usage() break De esta forma, EARGF ejecutaría la función que indica cómo se debe usar el programa (y aborta la ejecución) cuando se usa la opción -d sin ningún argumento. En nuestro caso, tenemos un if adicional para comprobar que el argumento tiene al menos los dos caracteres que necesitamos. La mayoría de los programas de Plan 9 que aceptan varias opciones usan estas macros para procesarlas. Esto significa que la sintaxis de invocación es similar en la mayoría de los programas. Como ya hemos visto, podemos combinar las opciones en un único argumento, usar varios argumentos como opciones, proporcionar argumentos a las opciones inmediatamente después de la letra correspondiente, terminar el procesamiento de las opciones con --, etc. Como ya habrás notado, el programa acaba su ejecución llamando a exits, cuya página de manual es exits(2). Esta llamada al sistema acaba con el proceso que la llama. El proceso puede dejar una cadena de caracteres como único legado. Dicha cadena de caracteres informará de lo

12 que le ha ocurrido. Esta cadena informa sobre el estatus de salida del programa, esto es, qué le ha pasado al programa. Si se llama con una cadena vacía o con un puntero a nil, entonces la convención dice que el proceso ha salido con un estatus correcto, y que todo salió bien el proceso ha cumplido con su trabajo y ha acabado. En otro caso, se considera que no ha acabado bien, y la cadena describe el problema que tuvo el proceso para realizar su trabajo. Por ejemplo sic.c #include <u.h> #include <libc.h> void main(int, char*[]) { exits("sic!") reportaría la cadena sic! al sistema cuando exits acaba la ejecución del proceso. La siguiente ejecución muestra el estatus del proceso, haciendo un echo de $status. Así podemos saber el estatus del último comando que se ejecutó en el shell, en este caso, el programa salió quejándose porque es un programa depresivo (los programas también tienen sus momentos de crisis): 8.sic echo $status 8.sic 2046: sic! Los programas deben salir con el estatus apropiado dependiendo de lo que les haya pasado. Por tanto, ls acaba con éxito cuando puede listar los ficheros que se le han pasado como argumentos, y reporta fallo cuando no puede listarlos. De la misma manera, rm acaba con éxito cuando puede borrar los ficheros que se le han indicado, y acaba con un estatus erróneo cuando no puede hacerlo. Lo mismo se aplica a los demás comandos. Antes, cuando dijimos que un programa empieza ejecutando en main, mentimos (no nos lo tengas en cuenta). No lo hace. En realidad, empieza a ejecutar otra función, que es la que llama a main, y que cuando main retorna, llama a exits para acabar la ejecución. Esta es la razón por la que nuestros programas siempre acaban de ejecutar cuando llegan al final de main. No hay nada mágico en ello. Un proceso no termina de ejecutar simplemente porque una función retorne (su flujo de ejecución no desaparece). Sin embargo, como el proceso es una abstracción del sistema operativo, podemos usar una llamada al sistema para acabar con un proceso. El sistema libera todos los recursos que estaba consumiendo y el proceso pasa a la historia. Al fin y al cabo, un proceso no es más que una estructura de datos. En pocas palabras, si nuestro programa no llama a exits, la función que llama a main realizará esa llamada al sistema cuando main retorne. Pero es mucho mejor que llamemos explícitamente a exits desde nuestro programa. De otra forma, no podemos estar seguros del valor que se usará como estatus de salida Errores en las llamadas al sistema En este capítulo y en los sucesivos, realizaremos muchas llamadas al sistema desde programas escritos en C. En la mayoría de los casos no habrá problemas con las llamadas que se realicen. Pero en otros casos podemos cometer errores y la llamada al sistema no podrá realizar su trabajo. Por ejemplo, esto puede ocurrir cuando tratamos de cambiar el directorio de trabajo del proceso a un directorio que no existe. Prácticamente todas las funciones que vamos a usar (las llamadas al sistema también son funciones) pueden tener problemas para completar su trabajo. En Plan 9, cuando una llamada al sistema encuentra un error o no es capaz de hacer su trabajo, la función retorna un valor que alerta

13 de ello. Dependiendo de la función, el valor que indica el fallo de la misma puede cambiar. En general, un valor de retorno absurdo indica que el trabajo no se ha podido realizar correctamente. Por ejemplo, la llamada al sistema open (que veremos más adelante) devuelve un número entero positivo. Sin embargo, si falla, retorna -1. Esa es la convención para la mayoría de llamadas al sistema que devuelven un valor entero. Las llamadas que devuelve una cadena de caracteres devuelven un puntero nulo ( nil) en caso de error. En todo caso, la página de manual de una llamada al sistema indica su valor de retorno en caso de error. Siempre debemos comprobar errores. No comprobar errores es como conducir a ciegas. Si no compruebas errores, prepárate para una depuración infernal. Hay un libro excelente que debería leer todo programador y que enseña problemas prácticos relacionados con la programación y las técnicas para evitar horas de depuración [1]. Aunque las llamadas al sistema nos avisen de los errores retornando un valor absurdo, Plan 9 guarda una cadena de caracteres con la descripción del error. Esta cadena de error nos da información sobre el error y es muy útil para arreglar el problema. Creenos, querrás imprimirla para saber lo que ha pasado cuando te encuentres con problemas. Hay varias formas de imprimir esa cadena. La mejor de ellas es usar el formato %r con print. Este formato hace que print print pida a Plan 9 la cadena de error y la imprima junto con otra salida que le hayamos dado. Este programa de ejemplo usa el formato. err.c #include <u.h> #include <libc.h> void main(int, char* []) { if (chdir("magic") < 0){ print("chdir failed: %r\n") exits("failed") /*... do other things... */ exits(nil) Ejecutemos el programa: 8.err chdir failed: magic file does not exist El programa intentó usar chdir para cambiar el directorio de trabajo al directorio magic. El problema es que ese directorio no existe, y la llamada al sistema ha fallado y ha retornado -1. Un buen programa debe comprobar que chdir no devuelve -1 cuando se le llama, y si ocurre, debe reportar el problema al usuario. Fíjate que usamos el formato %r en print para informar del error al usuario. Si el programa no puede seguir por culpa del error, debe abortar su ejecución indicando que ha fallado. A esto se le llama un error fatal. Esto es tan común que hay una función que imprime un mensaje y después sale del programa. Dicha función se llama sysfatal y se usa como sigue: if (chdir("magic") < 0) sysfatal("chdir failed: %r") En algunos casos necesitaremos obtener la cadena de error de la llamada al sistema que ha

14 fallado. Por ejemplo, para modificarla e imprimirla en un mensaje adaptado a nuestras necesidades. La llamada al sistem rerrstr lee la cadena de error y la almacena como una cadena de caracteres en un buffer que le debemos proporcionar. Veamos un ejemplo: char error[128]... rerrstr(error, sizeof error) Después de la llamada, error contendrá la cadena de error. Cualquier función que se ofrece desde una biblioteca debe reportar sus errores. Si estamos escribiendo una función de este tipo, debemos pensar cómo hacerlo. Una forma es usar el mismo mecanismo que usa Plan 9. Esto está bien ya cualquier programador puede usar nuestra biblioteca y tratar sus errores como trata los errores del sistema, sin importarle si es una biblioteca o es una llamada al sistema. La llamada al sistem werrstr escribe un nuevo valor en la cadena de error. Se usa como la función print. Utilizando esta función, podemos implementar otra función que saque un elemento de una pila y avisa de los errores de una forma adecuada: int pop(stack * s) { if (isempty(s)){ werrstr("pop on an empty stack") return do the pop otherwise... Ahora podríamos escribir código como:... if (pop(s) < 0){ print("pop failed: %r\n")... Cuando haya un error en pop, se imprimirá algo como: pop failed: pop on an empty stack 2.5. Entorno Otra forma de dar argumentos a un proceso es definir variables de entorno. A cada proceso se le proporciona un conjunto de cadenas nombre=valor que se conocen como variables de entorno. Se usan para modificar el comportamiento de algunos programas. Es aconsejable definir una variable de entorno cuando se requiere un mismo argumento en repetidas ocasiones. Usualmente, todos los procesos que ejecutan en la misma ventana comparten las variables de entorno. Por ejemplo, la variable home contiene la ruta de nuestro directorio home. El comando cd usa dicha variable. De otra forma Cómo iba a saber cd cuál es nuestro directorio home? Tanto el nombre como el valor de una variable de entorno son cadenas de caracteres, no lo olvides. Podemos definir variables de entorno en un shell usando el símbolo de igual. Más adelante usaremos el shell para referirnos al valor de una variable de entorno, usando el símbolo del dólar. Después de leer las líneas de comandos, el shell reemplaza cada cadena que empieza por este símbolo por el valor de la variable de entorno con el nombre indicado después del mismo. Por ejemplo, el primer comando en la siguiente sesión define la variable de entorno dir:

15 dir=/a/very/long/path cd $dir pwd /a/very/long/path La segunda línea de comandos usa $dir y, por tanto, el shell reemplaza dicha cadena de caracteres por el valor de la variable de entorno llamada dir: /a/very/long/path. Ten en cuenta que cd no sabe nada sobre $dir. Podemos comprobar esto usando el comando echo, ya que este comando escribe sus argumentos tal y como los recibe: echo $dir /a/very/long/path Los siguientes dos comandos hacen lo mismo. Sin embargo, uno recibe un argumento y el otro no. La salida de pwd podría ser la misma después de cualquiera de ellos: cd $home cd En algunos casos es aconsejable definir una variable de entorno para la ejecución de un único comando, de tal forma que la variable sólo quede definida para ese proceso. Esto se puede hacer definiendo la variable en la misma línea, justo antes de indicar el nombre del comando a ejecutar, como en el siguiente ejemplo: temp=/tmp/foobar echo $temp /tmp/foobar echo $temp En este punto, podemos entender lo que significa $status. Es el valor de la variable de entorno status. El shell actualiza esta variable cada vez que sabe cómo acabó algún comando que ejecutó. Esto lo hace antes de sacar el prompt para recibir una nueva orden. El contenido de esa cadena es la cadena que usó el comando cuando llamó a exits. Otra variable interesante es $path. Esta variable es una lista de rutas donde el shell debe buscar el fichero ejecutable del comando que ejecuta el usuario. Cuando tecleamos un comando, no tiene que empezar con / o con./, sino que el shell busca el ejecutable en los directorios que se especifican en esta variable (siguiendo el orden). Si se encuentra el ejecutable, se ordena al sistema que lo ejecute. Veamos el contenido de la variable path en un sistema Plan 9 típico: echo $path. /bin Contiene, en este orden, el directorio de trabajo (punto) y /bin. Si escribimos ls, el shell prueba con./ls, y si no existe, prueba con /bin/ls. Si escribimos ip/ping, el shell prueba con./ip/ping, y después con /bin/ip/ping. Verdad que es bastante simple? Otras dos variables de entorno que resultan bastante útiles son user, que contiene el nombre del usuario y sysname, que contiene el nombre de la máquina. Nos podemos definir tantas variables como queramos. Pero atención. Las variables de entorno normalmente se dejan de lado a la hora de depurar. Si un programa acepta argumentos de la línea de comandos, entonces pondremos los argumentos en la línea de comandos. Si necesitamos una variable de entorno para pasar un argumento al programa cada vez que se ejecuta, tal vez nos tengamos que replantear los argumentos que debe aceptar el programa. Este problema se puede solucionar fácilmente definiendo los valores por omisión apropiados para los argumentos de un programa. Los argumentos de la línea de comandos hacen que la invocación al programa

16 sea explícita, más clara a simple vista, y por tanto, más fáciles de depurar. Sin embargo, las variables de entorno se usan sin conocimiento del usuario. Debido a la sintaxis de las variables de entorno podemos tener problemas a la hora de ejecutar echo, o cualquier otro programa, con argumentos que contengan un dólar o un igual. Ambos caracteres son especiales. Podemos decirle al shell que tome esos caracteres literalmente, que no haga nada con ellos. Eso lo podemos hacer englobándolos entre comillas simples (quoting). De esta forma, el shell no hará nada con ellos, los escapará: echo $user nemo echo $user is $user $user is nemo Nótese que el shell siempre se comporta de la misma manera ante la misma línea de comandos. Por ejemplo, la primera palabra (que es el nombre del comando) no es especial, y podemos hacer esto: cmd=pwd $cmd /usr/nemo El escapado también funciona siempre de la misma forma. Probemos con el programa echo que implementamos hace tiempo: 8.echo this is weird 0: echo 1: this is 2: weird Como se puede observar, argv[1] contiene la cadena this is, incluyendo el espacio en blanco. El shell no partió la cadena en dos, porque la hemos escapado. Las nuevas líneas también se pueden escapar. echo how many lines how many lines El prompt es diferente porque el shell tiene que leer más entrada para completar la parte escapada, ya que hay una comilla simple sin cerrar. Cuando escapamos caracteres, les quitamos su significado especial. También funciona con la barra invertida: echo \ espera a que continue la línea... hasta que presionemos return echo imprime la línea vacía echo \ \ Para conseguir el valor de una variable de entorno desde un programa de C, podemos usar la llamada al sistema getenv. Cuando usemos esta llamada, debemos comprobar los errores. La llamada retorna una cadena de caracteres residente en memoria dinámica con el valor de la variable de entorno. En caso de que no exista la variable, retorna nil.

17 env.c #include <u.h> #include <libc.h> void main(int, char*[]) { char* home home = getenv("home") if (home == nil) sysfatal("we are homeless") print("home is %s\n", home) exits(nil) Si lo ejecutamos: 8.env home is /usr/nemo Una llamada relacionada es putenv, que acepta un nombre y un valor, y escribe la variable de entorno correspondiente. Tanto el nombre como el valor son cadenas de caracteres Nombres de proceso y estados El nombre de un proceso no es el nombre del programa que ejecuta. Cada proceso tiene un número único que lo identifica, otorgado por el sistema cuando comienza lo crea. Este número se llama id de proceso o pid. El pid identifica, por tanto, a un proceso. El pid de un proceso es un número entero, y el sistema intenta no reusarlos. El pid sirve para ordenar acciones sobre un proceso. En todo caso, no es más que un nombre que se inventa el sistema para cada proceso. La variable de entorno pid contiene el pid del shell. Ten en cuenta que el valor de una variable de entorno es una cadena de caracteres, no un entero. Esta variable de entorno es bastante útil para crear ficheros temporales para un shell en concreto. Para conseguir el pid del proceso que ejecuta nuestro programa, podemos usar getpid: pid.c #include <u.h> #include <libc.h> void main(int, char*[]) { int pid pid = getpid() print("my pid is %d\n", pid) exits(nil)

18 Si ejecutamos este programa: 8.pid my pid is pid my pid is 372 El primer proceso tenía el pid 345. También se puede decir que el primer proceso era el 345. El segundo era el 372. Cada vez que ejecutamos un programa, el proceso tendrá un pid diferente. El comando ps (process status) lista los procesos del sistema. El segundo campo de cada línea (hay una línea por proceso) es el pid. Veamos un ejemplo: ps nemo 280 0:00 0: K Pread rio nemo 281 0:02 0: K Pread rio nemo 303 0:00 0: K Await rio nemo 305 0:00 0: K Await rc nemo 306 0:00 0: K Await rio... el resto de la salida se omite... El último campo de una línea indica el programa que está ejecutando el proceso. El tercer campo empezando por la derecha indica la cantidad de memoria virtual que usa el proceso. Ya podemos saber cuánta memoria consume nuestro programa cuando se carga. El segundo campo por la derecha es muy interesante. Veremos nombres como Pread y Await. Esos nombres reflejan el estado del proceso. El estado del proceso indica lo que está haciendo el proceso en este justo instante. Por ejemplo, los procesos 280 y 281, que están ejecutando rio, están leyendo algo (Pread), y el resto de los procesos listados a continuación están esperando a que algo ocurra (Await). Para entender esto, es necesario saber antes como implementa el sistema operativo la abstracción de proceso. En este caso, sólo tenemos un procesador, pero hay múltiples procesos que parecen ejecutar simultáneamente. Esto forma parte de la abstracción de proceso. Hay múltiples programas que ejecutan independientemente del resto. Ninguno de ellos transfiere el control a los demás. Además, el procesador provee de un único flujo de control. Lo que ocurre es que cuando un proceso entra al kernel realizando una llamada al sistema, o por una interrupción, el sistema guarda el estado del proceso (esencialmente, el valor de los registros), y salta a otro proceso recuperando su estado anteriormente guardado. Si se conmuta de un proceso a otro lo suficientemente rápido, como puede hacerse con los procesadores actuales, parece que todos los procesos ejecutan al mismo tiempo. A cada proceso se le asigna una pequeña cantidad de tiempo del procesador, y cuando se agota, se salta a otro proceso. Esta porción de tiempo se conoce como quantum o cuanto, y suele rondar los 100 ms, que es un tiempo considerable teniendo en cuenta la velocidad de los procesadores modernos. La transferencia de control de un proceso a otro se denomina cambio de contexto, debido a que el estado de un proceso (registros, pila, etc.) se denomina contexto. Es importante tener claro que el que realiza la transferencia de control es el kernel O acaso metemos jumps a otros programas en nuestros programas? No. El sistema se encarga de realizar los cambios de contexto. La parte del kernel que decide al proceso al que le toca ejecutar se llama planificador o scheduler, porque planifica la ejecución de los procesos. Se llama planificación o scheduling a las decisiones tomadas por el planificador para multiplexar el procesador entre los distintos procesos. En Plan 9, y en la mayoría de los otros sistemas, el planificador es capaz de quitar y dar el procesador a los procesos sin que estos tengan que realizar una llamada al sistema. Para ello, se utilizan las interrupciones. A este tipo de planificación se la denomina preemptive scheduling, que se suele traducir como planificación expulsiva o planificación apropiativa.

19 Cuando hay un único procesador, sólo puede haber un proceso ejecutando (running), y el resto estará listo (ready) para ejecutar. Esos son dos de los estados que puede tener un proceso (running y ready). Fíjate en la figura 2.4. El proceso que está ejecutando pasa a estar listo para ejecutar cuando se acaba su tiempo de procesador. Entonces, el sistema elige otro proceso para que pase a estar ejecutando. Los estados no son otra cosa que constantes definidas por el sistema para implementar la abstracción de proceso. En ocasiones, un proceso puede estar leyendo de un terminal, de una conexión de red, o de algún dispositivo. En esos casos, el proceso tiene que esperar a que le lleguen los datos. El proceso podría esperar en un bucle, pero sería un despilfarro de procesador. La idea es que cuando un proceso tiene que esperar por entrada/salida, el sistema elige a otro proceso para ejecutar. Los dispositivos de entrada/salida son muy lentos comparados con el procesador. Mientras que un proceso está leyendo o escribiendo en un dispositivo, otro proceso puede usar el procesador para ejecutar una gran cantidad de sus instrucciones. El tiempo necesario para ejecutar unas cuantas instrucciones, comparado con el necesario para hacer entrada/salida, es muy reducido. Es como comparar el tiempo necesario para ir a tu casa con el tiempo necesario para ir a la luna. Esta idea es fundamental para el concepto de multiprogramación, que es como se llama a las técnicas que permiten que varios programas puedan estar cargados en el mismo ordenador simultáneamente. Running Broken Muerte Nacimiento Ready Blocked Figura 2.4: Estados de los procesos y sus transiciones. Para permitir que un proceso no cuente a la hora de repartir el procesador, se le etiqueta como bloqueado (blocked). En realidad, éste es otro de los posibles estados. Todos los procesos que se listaron anteriormente están bloqueados. Por ejemplo, Pread y Await significan que el proceso está bloqueado (el primero indica que lo está para acabar una lectura). Cuando ocurre el evento por el que un proceso está esperando, el estado del proceso cambia y vuelve a estar listo para ejecutar. Entonces, en algún momento el sistema le elegirá para ejecutar y tendrá su rebanada de tiempo. En Plan 9, el estado mostrado para los procesos que están bloqueados indica la razón por la que lo están. Por eso, ps muestra distintos estados. Esto nos ayuda a saber qué está pasando con nuestros procesos. Hay otro estado, roto (broken), que significa que un proceso ha tenido un error y ha dejado de ejecutar. Cuando un proceso hace algo ilegal (por ejemplo, tiene un error), queda en este estado. Por ejemplo, dividir entre cero o dereferenciar un puntero nulo causa una excepción (un error). Las excepciones, como las interrupciones, son tratadas por el hardware y el sistema se encarga de manejarlas. Después de un error de este tipo en un proceso, el sistema lo deja roto. Un proceso roto no ejecuta nunca más, pero el sistema guarda su estado para que lo podamos depurar. Una vez depurado, podemos pedir al sistema que lo elimine de la lista de procesos.

20 Depuración Cuando hemos cometido un error programando y nuestro programa se queda roto, es de gran utilidad saber qué le ha pasado. Hay varias formas de descubrirlo. Para probarlas, vamos a escribir un programa que falle. El programa imprimirá un saludo con el nombre que se le pase como argumento, pero lo hará sin comprobar que se le ha pasado al menos un argumento y además lo imprimirá sin usar el formato adecuado de print. hi.c #include <u.h> #include <libc.h> void main(int, char*argv[]) { /* Wrong! */ print("hi ") print(argv[1]) exits(nil) Si compilamos y ejecutamos el programa: 8.hi 8.hi 788: suicide: sys: trap: fault read addr=0x0 pc=0x000016ff La última línea es un mensaje impreso por el shell. Está esperando a que 8.hi termine su ejecución. Cuando acaba, el shell vio que algo salió mal e imprimió el mensaje de diagnóstico para avisar al usuario. Si imprimimos el valor de la variable de entorno status, veremos lo siguiente: echo $status 8.hi 788: sys: trap: fault read addr=0x0 pc=0x000016ff Por lo tanto, el legado que deja 8.hi al terminar su ejecución, su estatus de salida, es lo que imprime el shell si detecta errores. Podemos deducir si el estatus no proviene de una llamada a exits por parte de 8.hi. En este caso, lo que ha ocurrido es que se ha intentado leer la dirección de memoria 0x0. Esa dirección no es válida, no pertenece a ningún segmento del proceso. Cuando se intenta leer una dirección que no pertenece a ningún segmento del proceso, se levanta una excepción (un fallo). De eso mismo es de lo que nos está avisando el estatus del programa con la cadena: fault read addr=0x0. El estatus comienza con el nombre del programa y el pid del proceso, para que se pueda identificar rápidamente el programa que ha fallado. Después se da más información, como el contador de programa (PC) del proceso cuando se intentó leer la dirección 0x0, que era 0x000016ff. A continuación seguiremos con la autopsia del proceso. El programa src sabe cómo obtener el fichero fuente del programa y la línea que corresponde un contador de programa. src -n -s 0x000016ff 8.hi /sys/src/libc/fmt/dofmt.c:37 Hay que pasarle el nombre del binario como argumento. La opción -n hace que se imprima el nombre del fichero fuente y la línea indicada. Si no se usa, src pedirá al editor que muestre el fuente, seleccionando dicha línea. La opción -s nos permite pasar una dirección de memoria o un símbolo para localizar en el fuente. Por cierto, este programa es una fuente infinita de sabiduría. Si quieres saber cómo implementar, por ejemplo, cat, puedes ejecutar en un shell: