TEMA 2. GESTIÓN DE PROCESOS - Universidad de Almería

Diseño de Sistemas Operativos
Tema 2. Gestión de Procesos
Bloqueo de las señales. Un proceso puede controlar la llegada de las diferentes señales, pudiendo retrasar su
llegada bloqueándolas (se dice entonces que están pendientes). Cada proceso posee un conjunto llamado
máscara de señales, que contiene la lista de las señales bloqueadas. Este conjunto puede modificarse
mediante la llamada al sistema sigprocmask.
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);
El proceso puede solicitar al sistema su lista de señales pendientes por la llamada al sistema sigpending cuyo
prototipo es el siguiente:
int sigpending(sigset_t *set);
Desvío de señales. Control del comportamiento del proceso en la recepción de una señal.
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);
Espera de señales. La llamada al sistema pause no permite esperar una señal particular, el proceso se
suspende hasta que llegue cualquier señal. La norma POSIX ha regulado este problema con la introducción
de la llamada al sistema sigsuspend, que reemplaza temporalmente la máscara de señales del proceso por una
máscara de espera y suspende el proceso hasta la llegada de una señal que no pertenezca a la máscara de
espera.
int sigsuspend(const sigset_t *mask);
Gestión de las alarmas . Un proceso puede solicitar al sistema que le envíe una señal en un tiempo dado,
utilizando para ello la llamada al sistema alarm.
long alarm(long seconds);
La llamada al sistema alarm es limitada, pues no permite gestionar automáticamente una alarma. La gestión
del tiempo es únicamente relativa al tiempo real, pero puede ser interesante gestionar alarmas relativas al
tiempo de ejecución del proceso. Los sistemas BSD y System V han resuelto estos problemas introduciendo
dos nuevas llamadas al sistema que permiten gestionar automáticamente alarmas periódicas con referencias
de tiempo diferentes.
int getitimer(int which, struct itimerval *value);
int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue);
La señal SIGCHLD. Cuando un proceso termina, queda en estado Zombie hasta que un proceso padre tenga
conocimiento de su estado de finalización por una de las llamadas al sistema wait o wait4. El proceso padre
es avisado de la terminación de uno de sus hijos por el sistema, que le envíala señal SIGCHLD. La señal se
activa únicamente cuando el proceso padre realizar una de las llamadas al sistema citadas anteriormente.
En principio, bajo Linux la señal SIGCHLD se pone a SIG_IGN y el sistema no previene al padre de la
terminación de un hijo; el sistema realiza automáticamente la terminación del proceso hijo y éste desaparece
de la Tabla de Procesos.
La consideración de la señal SIGCHLD es importante en la escritura de aplicaciones cliente/servidor. En
general, un servidor maestro controla la llegada de peticiones y crea un servidor esclavo que responde a ellas.
Tras la petición, el servidor esclavo se termina y el servidor maestro verifica que no haya habido problemas
por la lectura de su código de terminación. Es necesario leer el estado de terminación, si no existe un riesgo
de saturación de la Tabla de Procesos por proceso en estado Zombie.
La información respecto a la gestión de las señales para un proceso se almacenan en la estructura de datos
task_struct (descriptor de proceso). Los campos de esta estructura relacionados con las señales son los
siguientes:
signal: señales en espera, expresadas en forma de cadena de bits.
blocked: señales ocultas, expresadas en forma de cadena de bits.
exit_signal: número de la señal que ha causado la finalización del proceso.
sig: tabla que contiene la dirección de las funciones de desvío de las señales.
La estructura signal_struct, que define el tipo de sig, se declara en el archivo linux/sched.h. Contiene los dos
campos siguientes:
int count: contador utilizado por la llamada al sistema clone para referenciar el número de proceso que
apuntan a la estructura.
struct sigaction[32] action: tabla de funciones de desvío.
Departamento de Lenguajes y Computación. Universidad de Almería Página 2.59