%% ipc.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
duplicazione dei file descriptor che abbiamo trattato in
sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
funzioni infatti che è possibile dirottare gli stream standard dei processi
-(che abbiamo visto in sez.~\ref{sec:file_std_descr} e
+(che abbiamo visto in tab.~\ref{tab:file_std_files} e
sez.~\ref{sec:file_std_stream}) sulla pipe. In
fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
quindi associato allo standard input) in caso di \code{"w"}.
-Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
-una pipe e non ad un file, e viene sempre aperto in modalità
+Lo \textit{stream} restituito da \func{popen} è identico a tutti gli effetti
+ai \textit{file stream} visti in sez.~\ref{sec:files_std_interface}, anche se
+è collegato ad una pipe e non ad un file, e viene sempre aperto in modalità
\textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
due nuove funzioni, \funcd{pclose}, il cui prototipo è:
Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo file speciale o in lettura o
-scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
-leggere, nel secondo al capo di ingresso, e dovrà scrivere.
+processo non avrà che da aprire il relativo \index{file!speciali} file
+speciale o in lettura o scrittura; nel primo caso sarà collegato al capo di
+uscita della fifo, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
+scrivere.
Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
essere acceduta contemporaneamente da più processi, sia in lettura che in
Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
-occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
-in modo che il linker dinamico possa accedervi.
-
-In generale questa variabile indica il \itindex{pathname} \textit{pathname}
-della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
-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:
+occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
+che il linker dinamico possa accedervi.
+
+In generale questa variabile indica il \textit{pathname} della directory
+contenente la libreria. Nell'ipotesi (che daremo sempre per 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}
[piccardi@gont sources]$ ./fortuned -n10
\end{Verbatim}
oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
per la programmazione di rete; e vedremo anche
-(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
-attraverso quella medesima interfaccia; vale però la pena esaminare qui una
-modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
- stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
- che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
-identici ad una pipe bidirezionale.
+(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei
+\index{file!speciali} file speciali (di tipo socket, analoghi a quello
+associati alle fifo) cui si accede però attraverso quella medesima
+interfaccia; vale però la pena esaminare qui una modalità di uso dei socket
+locali\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4, ma
+ è supportata in genere da qualunque sistema che fornisca l'interfaccia dei
+ socket.} che li rende sostanzialmente identici ad una pipe bidirezionale.
La funzione \funcd{socketpair} infatti consente di creare una coppia di file
descriptor connessi fra di loro (tramite un socket, appunto), senza dover
-ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
-analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
+ricorrere ad un \index{file!speciali} file speciale sul filesystem, i
+descrittori sono del tutto analoghi a quelli che si avrebbero con una chiamata
+a \func{pipe}, con la sola differenza è che in questo caso il flusso dei dati
+può essere effettuato in entrambe le direzioni. Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
\end{minipage}
\normalsize
\caption{La struttura \structd{ipc\_perm}, come definita in
- \file{sys/ipc.h}.}
+ \headfile{sys/ipc.h}.}
\label{fig:ipc_ipc_perm}
\end{figure}
\end{functions}
La funzione determina un valore della chiave sulla base di \param{pathname},
-che deve specificare il \itindex{pathname} \textit{pathname} di un file
-effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di
-norma viene specificato come carattere, dato che ne vengono utilizzati solo
-gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
- SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, la
- \acr{glibc} usa il prototipo specificato da XPG4, ma vengono lo stesso
- utilizzati gli 8 bit meno significativi.}
+che deve specificare il \textit{pathname} di un file effettivamente esistente
+e di un numero di progetto \param{proj\_id)}, che di norma viene specificato
+come carattere, dato che ne vengono utilizzati solo gli 8 bit meno
+significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
+ l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, la \acr{glibc}
+ usa il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli 8
+ bit meno significativi.}
Il problema è che anche così non c'è la sicurezza che il valore della chiave
sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
ed hanno lo stesso significato di quelli riportati in
tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
- simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
+ simboliche ivi definite occorrerà includere il file \headfile{sys/stat.h},
alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
\const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
\label{fig:ipc_msqid_ds}
\end{figure}
-A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
-kernel mantiene le principali informazioni riguardo lo stato corrente della
+A ciascuna coda è associata una struttura \struct{msqid\_ds}, la cui
+definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura
+il kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
sia una differenza con i campi mostrati nello schema di
fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
- \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
- struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono elencati i
-campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
-ultimi tre campi che sono previsti dalla implementazione originale di System
-V, ma non dallo standard Unix98.
+ \file{include/linux/msg.h}, e fanno riferimento alla definizione della
+ omonima struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono
+elencati i campi significativi definiti in \headfile{sys/msg.h}, a cui si sono
+aggiunti gli ultimi tre campi che sono previsti dalla implementazione
+originale di System V, ma non dallo standard Unix98.
Quando si crea una nuova coda con \func{msgget} questa struttura viene
inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
comunque superare il limite \const{MSGMAX}.
La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
-la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
-campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
-La sola cosa che conta è che la struttura abbia come primo membro un campo
-\var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
-messaggio e deve essere sempre specificato come intero positivo di tipo
-\ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
+la definizione contenuta in \headfile{sys/msg.h} usa esplicitamente per il
+secondo campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini
+pratici. La sola cosa che conta è che la struttura abbia come primo membro un
+campo \var{mtype} come nell'esempio; esso infatti serve ad identificare il
+tipo di messaggio e deve essere sempre specificato come intero positivo di
+tipo \ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
dimensione, e serve a contenere il testo del messaggio.
In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
attivare un meccanismo di ripristino attraverso l'uso del flag
\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
-\struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
+\kstruct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
strutture disallocate. Per mantenere coerente il comportamento queste
strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
richiede una operazione viene anzitutto verificato che tutte le operazioni
possono avere successo; se una di esse comporta il blocco del processo il
-kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo alla
coda di attesa associata a ciascun insieme di semafori\footnote{che viene
referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
di \struct{semid\_ds}.}.
immediatamente, dopo di che il kernel esegue una scansione della coda di
attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
operazioni sospese in precedenza può essere eseguita, nel qual caso la
-struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
+struttura \kstruct{sem\_queue} viene rimossa e lo stato del processo associato
all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
-per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
+per ciascun insieme di semafori una apposita struttura \kstruct{sem\_undo} che
contiene (nel vettore puntato dal campo \var{semadj}) un valore di
aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
per l'operazione.
+%TODO verificare queste strutture \kstruct{sem\_queue} e \kstruct{sem\_undo}
+
Queste strutture sono mantenute in due liste,\footnote{rispettivamente
attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
strutture se questo viene cancellato o per azzerarle se si è eseguita una
operazione con \func{semctl}; l'altra associata al processo che ha eseguito
l'operazione;\footnote{attraverso il campo \var{semundo} di
- \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
+ \kstruct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
processo termina, la lista ad esso associata viene scandita e le operazioni
applicate al semaforo. Siccome un processo può accumulare delle richieste di
ripristino per semafori differenti chiamate attraverso diverse chiamate a
Poi, per verificare che l'argomento specifichi effettivamente una directory,
si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
immediatamente in caso di errore. Questa funzione serve anche per impostare
-la directory di lavoro del programma nella directory da tenere sotto
-controllo, in vista del successivo uso della funzione
-\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
+la \index{directory~di~lavoro} directory di lavoro del programma nella
+directory da tenere sotto controllo, in vista del successivo uso della
+funzione \func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
particolare scopo del programma, che necessita comunque di restare
all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
con l'esecuzione in background come si conviene ad un programma demone; si
noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-directory di lavoro corrente. Una volta che il programma è andato in
-background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
-ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
-\func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
-bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
- 44}) si cancellano i valori precedentemente immagazzinati nella memoria
-condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
-degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
- 46}) si sblocca il mutex con \func{MutexUnlock}, e si attende
-(\texttt{\small 47}) per il periodo di tempo specificato a riga di comando con
-l'opzione \code{-p} con una \func{sleep}.
+\index{directory~di~lavoro} directory di lavoro corrente. Una volta che il
+programma è andato in background l'esecuzione prosegue (\texttt{\small
+ 42--48}) all'interno di un ciclo infinito: si inizia (\texttt{\small 43})
+bloccando il mutex con \func{MutexLock} per poter accedere alla memoria
+condivisa (la funzione si bloccherà automaticamente se qualche client sta
+leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
+immagazzinati nella memoria condivisa con \func{memset}, e si esegue
+(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
+\myfunc{dir\_scan}; infine (\texttt{\small 46}) si sblocca il mutex con
+\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
+specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
-sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+sia usata ancora una volta la funzione \myfunc{dir\_scan}, già utilizzata (e
descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
effettuare la scansione delle voci della directory, chiamando per ciascuna di
esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
contatori nella memoria condivisa, cui accede grazie alla
\index{variabili!globali} variabile globale \var{shmptr}.
-Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
-principale del programma, con un mutex acquisito, perciò non è necessario
-effettuare nessun controllo e si può accedere direttamente alla memoria
-condivisa usando \var{shmptr} per riempire i campi della struttura
+Dato che la funzione è chiamata da \myfunc{dir\_scan}, si è all'interno del
+ciclo principale del programma, con un mutex acquisito, perciò non è
+necessario effettuare nessun controllo e si può accedere direttamente alla
+memoria condivisa usando \var{shmptr} per riempire i campi della struttura
\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
dei file ed il loro numero, poi, utilizzando le macro di
tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
\itindend{memory~mapping}
-% TODO fare esempio di mmap anonima
+% TODO: fare esempio di mmap anonima
+
+% TODO: con il kernel 3.2 è stata introdotta un nuovo meccanismo di
+% intercomunicazione veloce chiamato Cross Memory Attach, da capire se e come
+% trattarlo qui, vedi http://lwn.net/Articles/405346/
+% https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcf634098c00dd9cd247447368495f0b79be12d1
\section{L'intercomunicazione fra processi di POSIX}
\label{sec:ipc_posix}
richiesto è che:
\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.
+ \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX}
+ byte e terminati da un carattere nullo.
\item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
nome dipende dall'implementazione.
Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
Krzysztof Benedyczak, e le relative informazioni si possono trovare su
- \href{http://www.geocities.com/wronski12/posix_ipc/index.html}
- {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
+ \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In
generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
che in casi più complessi la comunicazione può essere gestita direttamente con
La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+sez.~\ref{sec:file_open} dei quali però \func{mq\_open} riconosce solo i
seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
il messaggio. È pertanto opportuno eseguire sempre una chiamata a
-\func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
+\func{mq\_getattr} prima di eseguire una ricezione, in modo da ottenere la
dimensione massima dei messaggi sulla coda, per poter essere in grado di
allocare dei buffer sufficientemente ampi per la lettura.
\const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
\const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
-un puntatore ad una struttura \struct{sigval\_t} (definita in
+un puntatore ad una struttura \struct{sigval} (definita in
fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
\const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+sez.~\ref{sec:file_open} dei quali però \func{shm\_open} riconosce solo
i seguenti:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
\var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
+ \item[\errcode{EACCES}] il semaforo esiste ma non si hanno permessi
sufficienti per accedervi.
\item[\errcode{EEXIST}] si sono specificati \const{O\_CREAT} e
\const{O\_EXCL} ma il semaforo esiste.
L'argomento \param{name} definisce il nome del semaforo che si vuole
utilizzare, ed è quello che permette a processi diversi di accedere allo
-stesso semaforo. Questo deve essere specificato con un pathname nella forma
-\texttt{/qualchenome}, che non ha una corrispondenza diretta con un pathname
-reale; con Linux infatti i file associati ai semafori sono mantenuti nel
-filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato automaticamente
-un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
- corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
+stesso semaforo. Questo deve essere specificato con un \textit{pathname} nella
+forma \texttt{/qualchenome}, che non ha una corrispondenza diretta con un
+\textit{pathname} reale; con Linux infatti i file associati ai semafori sono
+mantenuti nel filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato
+automaticamente un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha
+ cioè una corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
La seconda variante di \func{sem\_wait} è una estensione specifica che può
essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
-ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+ad un valore di 600 prima di includere \headfile{semaphore.h}, la funzione è
+\funcd{sem\_timedwait}, ed il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
+ \item[\errcode{EACCES}] non si hanno i permessi necessari a cancellare il
semaforo.
\item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
\item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
semantica usata con \func{unlink} per i file, trattata in dettaglio in
-sez.~\ref{sec:file_link}.
+sez.~\ref{sec:link_symlink_rename}.
Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
anche essere utilizzati anche in forma anonima, senza necessità di fare
% LocalWords: dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
% LocalWords: memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
% LocalWords: SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
-% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr DirScan ipcs NFS
+% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr ipcs NFS
% LocalWords: ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
% LocalWords: LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
% LocalWords: UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP
% LocalWords: EBUSY sigev SIGNAL signo value sigval siginfo all'userid MESGQ
% LocalWords: Konstantin Knizhnik futex tmpfs ramfs cache shared swap CONFIG
% LocalWords: lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
-% LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED EACCESS has
+% LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED has
% LocalWords: ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
% LocalWords: process getvalue sval execve pshared ENOSYS heap PAGE destroy it
% LocalWords: xffffffff Arrays owner perms Queues used bytes messages device
projects / gapil.git / blobdiff