Sistemas operativos modernos

trabajo monousuario, incluso cuando el usuario está ausente, se ejecutan docenas de procesos en segundo plano, llamados demonios (daemons). Estos se inician en forma automática cuando se arranca el sistema. (Se usa el término “demonio” por su connotación de espíritu maligno que trabaja por su cuenta.) Un demonio representativo es cron, que se activa cada minuto para ver si tiene trabajo. Si lo tiene, lo efectúa, y luego se desactiva otra vez hasta la siguiente verificación. Este demonio es necesario porque en UNIX es posible calendarizar acfividades a realizar minutos, horas, días o incluso meses en el futuro. Por ejemplo, supongamos que el usuario fie­ ne una cita con el dentista a las 3 p.m. el martes siguiente. Podría crear una entrada en la base de datos del demonio cron para indicarle que emita una alarma sonora a las 2:30, por ejemplo. Cuando llega el día y la hora indicados, el demonio cron ve que fiene trabajo que hacer e ini­ cia el programa de alarma sonora como proceso nuevo. El demonio cron también sirve para iniciar actividades periódicas, como efectuar respaldos de disco diarios a las 4 a.m. o recordar a usuarios olvidadizos que el 31 de octubre de cada año deben abastecerse de golosinas para el día de brujas. Otros demonios se encargan del correo electrónico enviado y recibido, administran la cola de la impresora, verifican si hay suficientes páginas libres en la memoria, etc. La implementación de los demonios es sencilla en UNIX por­ que cada uno es un proceso individual, independiente de todos los demás. La creación de procesos en UNIX es excepcionalmente sencilla. La llamada al sistema fork (bifurcarse) crea una copia exacta del proceso original. El proceso que se bifurcó se denomina proceso padre; el nuevo es el proceso hijo. Tanto el padre como el hijo tienen su propia ima­ gen de memoria privada. Si el padre cambia después cualquiera de sus variables, el hijo no ve­ rá los cambios, y viceversa. El padre y el hijo comparten los archivos que estén abiertos. Es decir, si cierto archivo es­ taba abierto en el padre antes del fork, seguirá estando abierto después, tanto en el padre como en el hijo. Los cambios efectuados al archivo por cualquiera de ellos serán visibles para el otro. Este comportamiento es razonable porque dichos cambios también serán visibles para cual­ quier proceso no relacionado que abra el archivo. El hecho de que las imágenes de memoria, variables, registros y todo lo demás sean idénfi­ cos en el padre y en el hijo da pie a una pequeña dificultad: ¿cómo saben los procesos cuál de ellos debe ejecutar el código del padre y cuál el código del hijo? El secreto es que la llamada al sistema fork devuelve un Oal hijo y un valor distinto de cero, el identificador de proceso (PID; Process IDentifier), al padre. Lo normal es que ambos procesos verifiquen el valor devuelto y actúen de manera acorde, como se muestra en la figura 10-4. El nombre de un proceso es su PID. Cuando se crea un proceso, el padre recibe el PID del hijo, como ya dijimos. Si el hijo quiere conocer su propio PID, hay una llamada al sistema, getpid, que lo proporciona. Los PIDs se usan de varias maneras. Por ejemplo, cuando un hijo termina, el padre recibe el PID del hijo que acaba de terminar. Esto puede ser importante por­ que un padre podría tener muchos hijos. Puesto que los hijos también pueden tener hijos, un proceso original puede generar todo un árbol de hijos, nietos y demás descendientes. Los procesos en UNIX pueden comunicarse entre sí empleando una forma de transferencia de mensajes. Es posible crear un canal entre dos procesos en el que un proceso pueda escribir un flujo de bytes para que el otro lo lea. Estos canales se denominan canalizaciones. Puede ha-