Linguaggio C - librerie standard per la gestione dei processi

	la nascita di un nuovo processo (fork())
	l'attesa di un processo figlio (wait())
	la trasformazione di un processo corrente (funzioni del gruppo exec())
	l'invio di segnali fra processi (libreria signal.h)
	la condivisione di file a scopo di comunicazione o sincronizzazione fra processi (pipe)

Generalita' sui processi (Unix)

Ogni processo Unix e' contraddistinto da un identificatore di processo (process ID) indicato con pid e da un identificatore del processo padre che viene indicato con ppid (parent process ID).

Il processo padre (parent process) e' il processo che genera un altro processo, detto processo figlio (child process).
Piu' propriamente il processo padre dovrebbe essere chiamato processo genitore dall'inglese (parent=genitore), ma il termine padre si adatta ugualmente bene allo scopo.

Il pid e' un numero univoco in un determinato istante, fornito dal sistema operativo e necessario ad identificare un processo in "corso" sul sistema.

Il ppid e' l'identificativo del padre del processo che si sta' esaminando. In altri termini il ppid e' il pid del processo che ha generato il processo considerato.

Un processo si puo' trovare in uno dei seguenti stati:

	Ready	E' pronto per essere eseguito.
	Running	E' in esecuzione su una CPU del sistema.
	Sleeping	Attende un evento.
	Swapped	Parte del processo e' stato trasferito su disco, per liberare la memoria per altri processi.
	Terminated	Il processo e' terminato. Invio del segnale SIGCHLD al parent.
	Zombie	Il processo ha terminato la sua esecuzione, ma il parent non ha raccolto il segnale SIGCHLD. Il processo mantiene ancora allocate delle risorse.

Fork di un processo

Un processo, durante la sua esecuzione, puo' creare un nuovo processo tramite la system call fork().
Il processo corrente e' detto processo padre o parent process, mentre il nuovo processo e' detto processo figlio o child process. Entrambi i processi condividono lo stesso codice programma ma vengono eseguiti in concorrenza fra loro assieme al resto dei processi elaborati sul sistema in oggetto. Normalmente il padre e il figlio eseguono delle istruzioni differenti.
Il child process eredita i file aperti dal parent process. Questi possono costituire un mezzo di interazione fra i 2 processi.
Diversamente i dati (le variabili del programma), lo stack e l'ambiente (environment) del parent process vengono duplicati per il nuovo processo e posti in un'area di memoria a lui riservata e non visibile dagli altri processi, parent compreso.

La fork() restituisce al parent o un valore negativo in caso di errore (il child process non viene generato), o un valore positivo corrispondente al pid del child.
La fork() ritorna al child un valore sempre nullo.

A titolo di esempio riporto un breve spezzone di codice:

In caso che venga rilevato un errore durante la creazione del nuovo processo, il codice deve essere in grado di gestirlo correttamente.
Nella figura sottostante, ho indicato in blu le istruzioni eseguite dal programma in caso di errore ritornato dalla system call fork().

Normalmente il processo padre esegue le istruzioni del programma, fino ad incontrare la chiamata alla fork() (istruzioni in blu). A questo punto il processo padre genera un nuovo processo. Da questo momento i 2 processi hanno vita indipendente e il risultato tornato dalla fork() e' differente per ciascun processo.
E' normale che i 2 processi eseguano percorsi differenti all'interno dello stesso programma (istruzioni in blu).

Attesa di un processo

Il processo padre termina prima del processo figlio. In questa situazione il child process rimane orfano del padre e viene adottato dal processo init che per definizione e' il padre di tutti i processi.

Il processo figlio termina, ma il padre non rileva il suo termine. Quando cio' si verifica, il processo figlio e' definito defunto oppure zombie e rimane in tale stato finche' o il padre non ha rilevato la sua terminazione, oppure fino a quando anche il padre termina; al termine del padre il processo figlio viene ereditato dal processo init che ne rileva la sua terminazione. Un processo zombie mantiene allocate le risorse fino quando non sia stato rilevato il suo stato di terminazione o dal processo padre o dal processo init.

Nella situazione di normalita', il padre deve quindi rilevare la terminazione del figlio tramite la system call wait(). Il figlio puo' cosi' rilasciare ogni risorsa impegnata.

Legenda della numerazione posta a fianco del flusso di processo:

1. E' in esecuzione il solo processo padre.
2. Il processo padre invoca la funzione fork(). Viene generato il processo figlio.
3. Il processo padre e' eseguito in concorrenza con il processo figlio (oltre agli altri processi running sul sistema).
   Se il padre invoca la funzione wait(), il padre attende la terminazione del figlio.
4. Il processo figlio e' eseguito in concorrenza con il processo padre (oltre agli altri processi running sul sistema).
5. Il figlio ha eseguito la terminazione del programma invocando la funzione _exit() o exit().
   Al padre e' inviato il segnale SIGCHLD.
6. Il padre ha rilevato la terminazione del figlio tramite la funzione wait() e le risorse impegnate dal figlio vengono liberate.
   Il processo padre riprende l'esecuzione fino alla sua terminazione.

Funzioni del gruppo exec

Comunicazione fra processi: la pipe

Le pipe (condotte) sono dei canali unidirezionali per la comunicazione fra processi.
Ogni processo puo' trattare le pipe come se fossero dei file standard, con le dovute eccezioni:

• Le pipe non sono fisicamente presenti sul file system, ma ad ogni pipe e' di norma associato un buffer di memoria dell'ordine di 4 kB.
• La creazione di una pipe genera due file descriptor: uno per gli accessi in scrittura utilizzabile dal processo produttore ed uno per gli accessi in lettura utilizzabile dal processo consumatore.
• Non e' possibile eseguire riposizionamenti su ciascun file descriptor (es. tramite la funzione seek()). Una volta che i dati siano stati letti o scritti, non e' possibile rileggerli o riscriverli.
• Gli accessi di lettura o di scrittura sono strettamente sequenziali (conseguenza diretta del punto precedente). La pipe puo' essere pensata come buffer circolare.
• Un file descriptor puo' essere aperto o in lettura o in scrittura, ma non in entrambi in modi (unidirezionalita' della pipe).

Le pipe costituiscono un meccanismo di sincronizzazione fra processo produttore e processo consumatore.

• Un processo che legge sulla pipe si blocca se la pipe e' vuota.
• Un processo che scrive sulla pipe si blocca se la pipe e' piena.

Un processo padre:

• Crea una pipe utilizzando la system call pipe()
• Effettua la fork() di uno o piu' processi.
• Gestisce la pipe creata o in input o in output.
• Al termine della gestione della pipe, viene atteso il processo figlio tramite la system call wait()
• Termine del processo padre.

In alternativa un processo padre puo' anche:

• Chiamare la funzione popen() che provvede a creare un nuovo processo eseguendo il comando passato in argomento alla popen() stessa.
  Il processo viene collegato da una pipe generata anch'essa da popen().
• Gestire la comunicazione in input o in output con il processo, tramite la pipe creata.
• Chiamare la funzione pclose() che attende il processo generato dalla popen().

Un processo consumatore (lettore della pipe):

• Utilizza il file descriptor di input della pipe.
• Impiega la system call read() per leggere i dati dalla pipe.
• Puo' utilizzare le funzioni fscanf(), fread(), fgetc(), fgets() previo impiego della fuzione fdopen() necessaria per associare uno stream al file descriptor della pipe.
• Gli viene restituito EOF quando i dati da leggere sulla pipe sono terminati e il processo produttore ha chiuso il file descriptor di output sulla pipe.
  
• Impiega la system call close() per chiudere il file descriptor della pipe.
  In alternativa puo' essere impiegata la funzione fclose() se in precedenza era stata chiamata la funzione fdopen().

Un processo produttore (scrittore della pipe):

• Utilizza il file descriptor di output della pipe.
• Impiega la system call write() per scrivere i dati sulla pipe.
• Puo' utilizzare le funzioni fprintf(), fwrite(), fputc(), fputs() previo impiego della fuzione fdopen() necessaria per associare uno stream al file descriptor della pipe.
• Riceve il segnale SIGPIPE nel caso che la pipe non possa piu' venire letta; tipicamente questa situazione si verifica quando il processo consumatore termina per un qualsiasi motivo o, piu' in generale, quando il processo consumatore chiude prematuramente il file descriptor della pipe (cioe' senza attendere che gli venga restituito EOF). In altri termini SIGPIPE segnala una condizione di anomalia sulla pipe.
• Impiega la system call close() per chiudere il file descriptor della pipe.
  In alternativa puo' essere impiegata la funzione fclose() se in precedenza era stata chiamata la funzione fdopen().

Le funzioni per la gestione dei processi non sono definite da una libreria specifica, ma fanno riferimento a piu' librerie standard; pertanto per il loro utilizzo e' necessario includere gli headers appropriati come descritto nella sinopsi di ciascuna funzione. Es.:

#include <unistd.h>
#include <sys/wait.h>

Funzioni della libreria stdlib.h

Funzioni della libreria stdio.h

Funzioni della libreria unistd.h

Funzioni della libreria sys/wait.h

Funzioni della libreria signal.h

Indice linguaggio C	Indice librerie C
Umberto Zappi Home Page