From c9573f8de2329df3d9e879bc949fda42adfaac33 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 13 Jun 2010 15:45:37 +0000 Subject: [PATCH] Correzioni multiple e materiale sui posix timer e sigevent. --- fileadv.tex | 23 ++--- ipc.tex | 95 +++++++++++---------- listati/sigevent.h | 18 ++-- listati/sigval_t.h | 4 +- signal.tex | 207 ++++++++++++++++++++++++++++++++++++--------- 5 files changed, 235 insertions(+), 112 deletions(-) diff --git a/fileadv.tex b/fileadv.tex index 38bd320..c046e1c 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -2737,23 +2737,10 @@ operazioni, usando un vettore di \textit{control block}. Tramite questo campo si specifica quale è la natura di ciascuna di esse. Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent} -che serve a specificare il modo in cui si vuole che venga effettuata la -notifica del completamento delle operazioni richieste. La struttura è -riportata in fig.~\ref{fig:file_sigevent}; il campo \var{sigev\_notify} è -quello che indica le modalità della notifica, esso può assumere i tre valori: -\begin{basedescript}{\desclabelwidth{2.6cm}} -\item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica. -\item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo - chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di - questo è stato installato con \const{SA\_SIGINFO} gli verrà restituito il - valore di \var{sigev\_value} (la cui definizione è in - fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di - \struct{siginfo\_t}. -\item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo - \itindex{thread} \textit{thread} che esegue la funzione specificata da - \var{sigev\_notify\_function} con argomento \var{sigev\_value}, e con gli - attributi specificati da \var{sigev\_notify\_attribute}. -\end{basedescript} +(illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il +modo in cui si vuole che venga effettuata la notifica del completamento delle +operazioni richieste; per la trattazione delle modalità di utilizzo della +stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}. Le due funzioni base dell'interfaccia per l'I/O asincrono sono \funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una @@ -3033,7 +3020,7 @@ file in una sezione dello spazio di indirizzi del processo che lo ha allocato. \begin{figure}[htb] \centering - \includegraphics[width=14cm]{img/mmap_layout} + \includegraphics[width=12cm]{img/mmap_layout} \caption{Disposizione della memoria di un processo quando si esegue la mappatura in memoria di un file.} \label{fig:file_mmap_layout} diff --git a/ipc.tex b/ipc.tex index c50d0f4..ee901ad 100644 --- a/ipc.tex +++ b/ipc.tex @@ -190,7 +190,6 @@ fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma, il cui codice completo è disponibile nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti. - \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} @@ -656,24 +655,26 @@ verificata) che si facciano le prove direttamente nella directory dei sorgenti (dove di norma vengono creati sia i programmi che la libreria), il comando da dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare il server, facendogli leggere una decina di frasi, con: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./fortuned -n10 -\end{verbatim} +\end{Verbatim} +%$ Avendo usato \func{daemon} per eseguire il server in background il comando ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il programma resta un esecuzione in background, e senza avere associato un terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}): -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ps aux ... piccardi 27489 0.0 0.0 1204 356 ? S 01:06 0:00 ./fortuned -n10 piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux -\end{verbatim}%$ +\end{Verbatim} +%$ e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con il programma client; otterremo così: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./fortune Linux ext2fs has been stable for a long time, now it's time to break it -- Linuxkongreß '95 in Berlin @@ -692,7 +693,8 @@ Let's call it an accidental feature. [piccardi@gont sources]$ ./fortune Linux ext2fs has been stable for a long time, now it's time to break it -- Linuxkongreß '95 in Berlin -\end{verbatim}%$ +\end{Verbatim} +%$ e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci frasi tenute in memoria dal server. @@ -962,7 +964,7 @@ nullo, nel qual caso l'identificatore sar Il secondo livello di controllo è quello delle varie funzioni che accedono direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei controlli è simile a quello dei file, ed avviene secondo questa sequenza: -\begin{itemize} +\begin{itemize*} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. \item se l'user-ID effettivo del processo corrisponde o al valore del campo @@ -974,7 +976,7 @@ controlli valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso per il gruppo in \var{mode} è appropriato l'accesso è consentito. \item se il permesso per gli altri è appropriato l'accesso è consentito. -\end{itemize} +\end{itemize*} solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che a differenza di quanto avviene per i permessi dei file, fallire in uno dei passi elencati non comporta il fallimento dell'accesso. Un'ulteriore @@ -1058,25 +1060,27 @@ inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e stampa, cancellazione. I valori di default sono per l'uso delle code di messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa del tipo: -\begin{verbatim} +\begin{Verbatim} piccardi@gont sources]$ ./ipctestid Identifier Value 0 Identifier Value 32768 Identifier Value 65536 Identifier Value 98304 Identifier Value 131072 -\end{verbatim}%$ +\end{Verbatim} +%$ il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo ancora: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./ipctestid Identifier Value 163840 Identifier Value 196608 Identifier Value 229376 Identifier Value 262144 Identifier Value 294912 -\end{verbatim}%$ +\end{Verbatim} +%$ che ci mostra come il valore di \var{seq} sia in effetti una quantità mantenuta staticamente all'interno del sistema. @@ -1182,9 +1186,8 @@ file \procrelfile{/proc/sys/kernel}{msgmax}, \procrelfile{/proc/sys/kernel}{msgmnb} e \procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}. - \begin{figure}[htb] - \centering \includegraphics[width=15cm]{img/mqstruct} + \centering \includegraphics[width=13cm]{img/mqstruct} \caption{Schema della struttura di una coda messaggi.} \label{fig:ipc_mq_schema} \end{figure} @@ -1271,7 +1274,7 @@ prototipo Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}. - \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di + \bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo @@ -1326,7 +1329,7 @@ messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo Invia un messaggio sulla coda \param{msqid}. - \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso + \bodydesc{La funzione restituisce 0, e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda. @@ -1334,13 +1337,11 @@ messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}. - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un valore non positivo per \param{mtype}, o un valore di \param{msgsz} maggiore di \const{MSGMAX}. \end{errlist} - ed inoltre \errval{EFAULT} ed \errval{ENOMEM}. -} + ed inoltre \errval{EFAULT}, \errval{EINTR} ed \errval{ENOMEM}. } \end{functions} La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il @@ -2903,13 +2904,14 @@ il mutex, prima di uscire. Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando le funzioni di libreria occorre definire opportunamente \code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./dirmonitor ./ -\end{verbatim}%$ +\end{Verbatim} +%$ ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta che il server è in esecuzione, possiamo passare ad invocare il client per verificarne i risultati, in tal caso otterremo: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./readmon Ci sono 68 file dati Ci sono 3 directory @@ -2919,12 +2921,13 @@ Ci sono 0 socket Ci sono 0 device a caratteri Ci sono 0 device a blocchi Totale 71 file, per 489831 byte -\end{verbatim}%$ +\end{Verbatim} +%$ ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci permette di verificare che il totale dei file è giusto. Un controllo con \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di memoria condivisa e di un semaforo: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status @@ -2936,12 +2939,13 @@ key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages -\end{verbatim}%$ +\end{Verbatim} +%$ Se a questo punto aggiungiamo un file, ad esempio con \code{touch prova}, potremo verificare che, passati nel peggiore dei casi almeno 10 secondi (o l'eventuale altro intervallo impostato per la rilettura dei dati) avremo: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./readmon Ci sono 69 file dati Ci sono 3 directory @@ -2951,18 +2955,20 @@ Ci sono 0 socket Ci sono 0 device a caratteri Ci sono 0 device a blocchi Totale 72 file, per 489887 byte -\end{verbatim}%$ +\end{Verbatim} +%$ A questo punto possiamo far uscire il server inviandogli un segnale di \const{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto ripetendo la lettura, otterremo un errore: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ./readmon Cannot find shared memory: No such file or directory -\end{verbatim}%$ +\end{Verbatim} +%$ e inoltre potremo anche verificare che anche gli oggetti di intercomunicazione visti in precedenza sono stati regolarmente cancellati: -\begin{verbatim} +\begin{Verbatim} [piccardi@gont sources]$ ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status @@ -2972,8 +2978,8 @@ key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages -\end{verbatim}%$ - +\end{Verbatim} +%$ %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta @@ -3271,7 +3277,7 @@ POSIX prendono come primo argomento una stringa che indica uno di questi nomi; lo standard è molto generico riguardo l'implementazione, ed i nomi stessi possono avere o meno una corrispondenza sul filesystem; tutto quello che è richiesto è che: -\begin{itemize} +\begin{itemize*} \item i nomi devono essere conformi alle regole che caratterizzano i \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX} byte e terminati da un carattere nullo. @@ -3280,7 +3286,7 @@ richiesto nome dipende dall'implementazione. \item l'interpretazione di ulteriori \texttt{/} presenti nel nome dipende dall'implementazione. -\end{itemize} +\end{itemize*} Data la assoluta genericità delle specifiche, il comportamento delle funzioni è subordinato in maniera quasi completa alla relativa @@ -3375,7 +3381,6 @@ di messaggi POSIX alla memoria secondo quanto specificato da \param{oflag}. \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e \const{O\_EXCL} ma la coda già esiste. - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. \item[\errcode{EINVAL}] il file non supporta la funzione, o si è specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}. @@ -3383,7 +3388,8 @@ di messaggi POSIX non esiste. \end{errlist} ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT}, - \errval{EMFILE} ed \errval{ENFILE}.} + \errval{EMFILE}, \errval{EINTR} ed \errval{ENFILE}. +} \end{functions} La funzione apre la coda di messaggi identificata dall'argomento \param{name} @@ -3559,22 +3565,20 @@ Per inserire messaggi su di una coda sono previste due funzioni, \param{abs\_timeout}. - \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di + \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di errore; nel quel caso \var{errno} assumerà i valori: \begin{errlist} \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la coda è piena. \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len} eccede il limite impostato per la coda. - \item[\errcode{ENOMEM}] il kernel non ha memoria sufficiente. Questo - errore può avvenire quando l'inserimento del messaggio \item[\errcode{EINVAL}] si è specificato un valore nullo per \param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o un valore non valido per \param{abs\_timeout}. \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato effettuato entro il tempo stabilito. \end{errlist} - ed inoltre \errval{EBADF} ed \errval{EINTR}.} + ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.} \end{functions} Entrambe le funzioni richiedono un puntatore al testo del messaggio @@ -3704,10 +3708,11 @@ processo alla volta per ciascuna coda. Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento \param{notification}, che è un puntatore ad una apposita struttura -\struct{sigevent}, (definita in fig.~\ref{fig:file_sigevent}) introdotta dallo -standard POSIX.1b per gestire la notifica di eventi; per altri dettagli si può -vedere quanto detto in sez.~\ref{sec:file_asyncronous_io} a proposito dell'uso -della stessa struttura per l'invio dei segnali usati per l'I/O asincrono. +\struct{sigevent}, (definita in fig.~\ref{fig:struct_sigevent}) introdotta +dallo standard POSIX.1b per gestire la notifica di eventi; per altri dettagli +si può vedere quanto detto in sez.~\ref{sec:file_asyncronous_io} a proposito +dell'uso della stessa struttura per l'invio dei segnali usati per l'I/O +asincrono. Attraverso questa struttura si possono impostare le modalità con cui viene effettuata la notifica; in particolare il campo \var{sigev\_notify} deve diff --git a/listati/sigevent.h b/listati/sigevent.h index 6b6539a..28a8303 100644 --- a/listati/sigevent.h +++ b/listati/sigevent.h @@ -1,8 +1,12 @@ -struct sigevent -{ - sigval_t sigev_value; - int sigev_signo; - int sigev_notify; - void (*sigev_notify_function)(sigval_t); - pthread_attr_t *sigev_notify_attributes; +struct sigevent { + int sigev_notify; /* Notification method */ + int sigev_signo; /* Timer expiration signal */ + union sigval sigev_value; /* Value accompanying signal or + passed to thread function */ + /* Function used for thread notifications (SIGEV_THREAD) */ + void (*sigev_notify_function) (union sigval); + /* Attributes for notification thread (SIGEV_THREAD) */ + void *sigev_notify_attributes; + /* ID of thread to signal (SIGEV_THREAD_ID) */ + pid_t sigev_notify_thread_id; }; diff --git a/listati/sigval_t.h b/listati/sigval_t.h index 4097bae..d662306 100644 --- a/listati/sigval_t.h +++ b/listati/sigval_t.h @@ -1,4 +1,4 @@ -union sigval_t { +typedef union sigval { int sival_int; void *sival_ptr; -} +} sigval_t; diff --git a/signal.tex b/signal.tex index a147ae6..2a9b253 100644 --- a/signal.tex +++ b/signal.tex @@ -2598,28 +2598,30 @@ per la restituzione dei dati viene usato il campo \var{si\_value}. \includestruct{listati/sigval_t.h} \end{minipage} \normalsize - \caption{La unione \structd{sigval\_t}.} + \caption{La definizione dell'unione \structd{sigval}, definita anche come + tipo \type{sigval\_t}.} \label{fig:sig_sigval} \end{figure} -Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in +Questo è una \ctyp{union} di tipo \struct{sigval} (la sua definizione è in fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico, se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma \var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente anche nella struttura \struct{sigevent} (definita in - fig.~\ref{fig:file_sigevent}) che viene usata dai meccanismi di notifica - come quelli per l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o - le code di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per -restituire dati al gestore del segnale; in alcune definizioni essa viene -identificata anche come \code{union sigval}. + fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica + come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O + asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi + POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore +del segnale; in alcune definizioni essa viene identificata anche con +l'abbreviazione \type{sigval\_t}. A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun -valore per \struct{sigval\_t}; per questo motivo lo standard ha previsto una +valore per \struct{sigval}; per questo motivo lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo è: \begin{prototype}{signal.h} - {int sigqueue(pid\_t pid, int signo, const sigval\_t value)} + {int sigqueue(pid\_t pid, int signo, const union sigval value)} Invia il segnale \param{signo} al processo \param{pid}, restituendo al gestore il valore \param{value}. @@ -2833,11 +2835,11 @@ tab.~\ref{tab:sig_timer_clockid_types}. amministrativi.\\ \const{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono crescente (a partire da un tempo iniziale non - specificati) che non può essere modificato.\\ + specificato) che non può essere modificato.\\ \const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli aggiustamenti dovuti all'uso di NTP (viene usato per fare riferimento ad una fonte - hardware.\footnotemark\\ + hardware).\footnotemark\\ \const{CLOCK\_PROCESS\_CPUTIME\_ID}& contatore del tempo di CPU usato da un processo (il \textit{process time} di sez.~\ref{sec:sys_cpu_times}, nel totale di @@ -2951,7 +2953,7 @@ all'indirizzo puntato dall'argomento \param{res}. Come accennato il valore di questa risoluzione dipende sia dall'hardware disponibile che dalla implementazione delle funzioni, e costituisce il limite -minimo di un intervallo di tempo che si può indicare, qualunque valore si +minimo di un intervallo di tempo che si può indicare. Qualunque valore si voglia utilizzare nelle funzioni di impostazione che non corrisponda ad un multiplo intero di questa risoluzione, sarà troncato in maniera automatica. @@ -2966,9 +2968,10 @@ pu Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il -clock del processore non è unico) avendo queste in genere frequenze -leggermente diverse, otterremo dei valori dei contatori scorrelati fra loro -senza possibilità di sincronizzazione. +segnale di temporizzazione inviato ai processori non ha una sola provenienza) +in genere ciascuna di queste potrà avere delle frequenze leggermente diverse, +e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza +nessuna possibilità di sincronizzazione. Il problema si presenta, in forma più lieve, anche se la base di tempo è la stessa, dato che un sistema multiprocessore non avvia mai tutte le CPU allo @@ -2989,35 +2992,63 @@ associato al \textit{process time} di un processo, la funzione Ottiene l'identificatore dell'orologio di CPU usato da un processo. - \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di - errore, nel qual caso \var{errno} assumerà uno dei seguenti valori: + \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo + in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti + valori: \begin{errlist} \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo al \textit{process time} di un altro processo, e \param{pid} non corrisponde al processo corrente. - \item[\errcode{EPERM}] l'indirizzo di \param{res} non è valido. - \item[\errcode{ENOENT}] non c'è modo di avere un tempo affidabile. + \item[\errcode{EPERM}] il chiamante non ha il permesso di accedere alle + informazioni relative al processo \param{pid}. \item[\errcode{ESRCH}] non esiste il processo \param{pid}. \end{errlist} } \end{functions} -La funzione ritorna l'identificativo di un orologio di sistema associato ad un -processo - +La funzione ritorna l'identificativo di un orologio di sistema associato ad un +processo indicato tramite l'argomento \param{pid}. Un utente normale, posto +che il kernel sia sufficientemente recente da supportare questa funzionalità, +può accedere soltanto ai dati relativi ai propri processi. + +Del tutto analoga a \func{clock\_getcpuclockid}, ma da utilizzare per ottenere +l'orologio associato ad un \textit{thread} invece che a un processo, è +\funcd{pthread\_getcpuclockid},\footnote{per poter usare la funzione, come per + qualunque funzione che faccia riferimento ai \textit{thread}, occorre + effettuare il collegamento alla relativa libreria di gestione compilando il + programma con \texttt{-lpthread}.} il cui prototipo è: +\begin{functions} + \headdecl{pthread.h} + \headdecl{time.h} -% TODO trattare gli orologi ad alta definizione e le funzioni POSIX per gli -% stessi cioè: -% clock_getres clock_gettime clock_settime (vedi man page) + \funcdecl{int pthread\_getcpuclockid(pthread\_t thread, clockid\_t *clockid)} + + Ottiene l'identificatore dell'orologio di CPU associato ad un + \textit{thread}. + + \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo + in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti + valori: + \begin{errlist} + \item[\errcode{ENOENT}] la funzione non è supportata dal sistema. + \item[\errcode{ESRCH}] non esiste il \textit{thread} identificato + da \param{thread}. + \end{errlist} +} +\end{functions} -Abbiamo visto in sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di -\func{setitimer} derivata da BSD presenti delle limitazioni,\footnote{in - particolare la possibilità di perdere un segnale sotto carico.} tanto che -nello standard POSIX.1-2008 questa viene marcata come obsoleta, e ne viene -fortemente consigliata la sostituzione con nuova interfaccia definita dallo -standard POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. +Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile +ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in +sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di \func{setitimer} derivata +da BSD presenti delle serie limitazioni,\footnote{in particolare la + possibilità di perdere un segnale sotto carico.} tanto che nello standard +POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente +consigliata la sostituzione con nuova interfaccia definita dallo standard +POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa +interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto +di varie funzionalità è stato aggiunto solo in un secondo tempo. Una delle principali differenze della nuova interfaccia è che un processo può utilizzare un numero arbitrario di timer; questi vengono creati (ma non @@ -3031,9 +3062,9 @@ avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo Crea un nuovo timer Posix. - \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di - errore, nel qual caso \var{errno} assumerà uno dei valori già visti per - \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}: + \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ + in caso di errore, nel qual caso \var{errno} assumerà uno dei valori già + visti per \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}: \begin{errlist} \item[\errcode{EAGAIN}] fallimento nel tentativo di allocare le strutture dei timer. @@ -3045,10 +3076,21 @@ avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo } \end{functions} -La funzione richiede tre argomenti, il primo serve ad indicare quale tipo di -orologio - - fig.~\ref{fig:file_sigevent} +La funzione richiede tre argomenti: il primo argomento serve ad indicare quale +tipo di orologio si vuole utilizzare e prende uno dei valori di +tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è + previsto l'uso di \const{CLOCK\_MONOTONIC\_RAW} mentre + \const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_THREAD\_CPUTIME\_ID} + sono disponibili solo a partire dal kernel 2.6.12.} si può così fare +riferimento sia ad un tempo assoluto che al tempo utilizzato dal processo (o +\textit{thread}) stesso. + +Il secondo argomento richiede una trattazione più dettagliata, in quanto +introduce una struttura di uso generale, \struct{sigevent}, che viene +utilizzata anche da altre funzioni, come quelle per l'I/O asincrono (vedi +sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi +sez.~\ref{sec:ipc_posix_mq})) e che serve ad indicare in maniera generica un +meccanimo di notifica. \begin{figure}[!htb] \footnotesize \centering @@ -3058,11 +3100,83 @@ orologio \normalsize \caption{La struttura \structd{sigevent}, usata per specificare le modalità di notifica degli eventi relativi alle operazioni di I/O asincrono.} - \label{fig:file_sigevent} + \label{fig:struct_sigevent} \end{figure} +La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è +riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva + dipende dall'implementazione, quella mostrata è la versione descritta nella + pagina di manule di \func{timer\_create}.} il campo \var{sigev\_notify} è il +più importante essendo quello che indica le modalità della notifica, gli altri +dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono +riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di +nnotifica viene fatta impostando uno dei valori di +tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli +eventuali ulteriori argomenti necessari a secondo della scelta +effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione +(nel caso di uso dei \textit{thread}) di una funzione di modifica in un +\textit{thread} dedicato. +\begin{table}[htb] + \footnotesize + \centering + \begin{tabular}[c]{|l|p{10cm}|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \const{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\ + \const{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo + chiamante il segnale specificato dal campo + \var{sigev\_signo}; se il gestore di questo + segnale è stato installato con + \const{SA\_SIGINFO} gli verrà restituito il + valore specificato con \var{sigev\_value} (una + \ctyp{union} \texttt{sigval}, la cui definizione + è in fig.~\ref{fig:sig_sigval}) come valore del + campo \var{si\_value} di \struct{siginfo\_t}.\\ + \const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo + \itindex{thread} \textit{thread} che esegue la + funzione di notifica specificata da + \var{sigev\_notify\_function} con argomento + \var{sigev\_value}, se diverso da \const{NULL} il + \textit{thread} viene creato con gli attributi + specificati da \var{sigev\_notify\_attribute}.\\ + \const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse + modalità di \const{SIGEV\_SIGNAL}) che però viene + recapitato al \textit{thread} indicato dal campo + \var{sigev\_notify\_thread\_id}. Questa modalità + è una estensione specifica di Linux, creata come + supporto per le librerie di gestione dei + \textit{thread}, pertanto non deve essere usata + da codice normale.\\ + \hline + \end{tabular} + \caption{Valori possibili per il campo \var{sigev\_notify} in una struttura + \struct{sigevent}.} + \label{tab:sigevent_sigev_notify} +\end{table} +Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo +argomento l'indirizzo di una di queste strutture per indicare le modalità con +cui si vuole essere notificati della scadenza del timer, se non si specifica +nulla (passando un valore \const{NULL}) verrà inviato il segnale +\const{SIGALRM} al processo corrente, o per essere più precisi verrà +utilizzato un valore equivalente all'aver specificato \const{SIGEV\_SIGNAL} +per \var{sigev\_notify}, \const{SIGALRM} per \var{sigev\_signo} e +l'identificatore del timer come valore per \var{sigev\_value.sival\_int}. + + +Il terzo argomento deve essere l'indirizzo di una variabile di tipo +\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena +creato, da usare in tutte le successive funzioni di gestione. Una volta creato +questo identificativo resterà univoco all'interno del processo stesso fintanto +che il timer non viene cancellato. + +Si tenga presente che eventuali POSIX timer creati da un processo non vengono +ereditati dai processi figli creati con \func{fork} e che vengono cancellati +nella esecuzione di un programma diverso attraverso una delle funzioni +\func{exec}. % TODO trattare i Posix timer, e le fuzioni: @@ -3071,7 +3185,20 @@ orologio \subsection{Le interfacce per la notifica attraverso i file descriptor} \label{sec:sig_signalfd_eventfd} - + +I segnali sono uno dei meccanismi classici, presenti da sempre nei sistemi +unix-like, per effettuare notifiche ai processi, la loro interfaccia però si è +dimostrata quasi subito poco azzeccata, in particolare per i problemi che si +vengono a creare con le funzioni di gestione dell'I/O multiplexing (vedi +sez.~\ref{sec:file_multiplexing}).\footnote{i temi trattati in questa sezione + presuppongono la conoscenza dell'I/O multiplexing si consiglia pertanto una + lettura di sez.~\ref{sec:file_multiplexing} qualora non si conosca + l'argomento. } Per questo motivo nello sviluppo del kernel si è pensato di +introdurre un meccanismo alternativo per la notifica dei segnali (ed anche di +eventi generici) basato direttamente sull'uso di file descriptor. + + + % TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22 % timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25 -- 2.30.2