attraverso cui fluiscono i dati.
La funzione che permette di creare questa speciale coppia di file descriptor
-associati ad una \textit{pipe} è appunto \func{pipe}, ed il suo prototipo è:
+associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int pipe(int filedes[2])}
(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
processo riceverà il segnale \errcode{EPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del manipolatore, o qualora
-il segnale sia ignorato o bloccato).
+restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
+segnale sia ignorato o bloccato).
La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
importante informazione riguardo il comportamento delle operazioni di lettura
utilizzarla per fare da tramite fra output ed input di due programmi invocati
in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
che permettono di sintetizzare queste operazioni. La prima di esse si chiama
-\func{popen} ed il suo prototipo è:
+\funcd{popen} ed il suo prototipo è:
\begin{prototype}{stdio.h}
{FILE *popen(const char *command, const char *type)}
pipe e non ad un inode\index{inode}, e viene sempre aperto in modalità
\textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
-funzioni, \func{pclose}, il cui prototipo è:
+funzioni, \funcd{pclose}, il cui prototipo è:
\begin{prototype}{stdio.h}
{int pclose(FILE *stream)}
che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
identici ad una pipe bidirezionale.
-La funzione \func{socketpair} infatti consente di creare una coppia di file
+La funzione \funcd{socketpair} infatti consente di creare una coppia di file
descriptor connessi fra di loro (tramite un socket\index{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},
la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
sempre il rischio che questa chiave possa essere stata già utilizzata da
qualcun altro. Dato che non esiste una convenzione su come assegnare queste
-chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
-\func{ftok}, che permette di ottenere una chiave specificando il nome di un
-file ed un numero di versione; il suo prototipo è:
+chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
+apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
+nome di un file ed un numero di versione; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
quello di permettere a processi diversi di scambiarsi dei dati.
La funzione che permette di richiedere al sistema l'identificatore di una coda
-di messaggi esistente (o di crearne una se questa non esiste) è \func{msgget};
-il suo prototipo è:
+di messaggi esistente (o di crearne una se questa non esiste) è
+\funcd{msgget}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\end{itemize}
Una volta creata una coda di messaggi le operazioni di controllo vengono
-effettuate con la funzione \func{msgctl}, che (come le analoghe \func{semctl}
+effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
prototipo è:
\begin{functions}
Una volta che si abbia a disposizione l'identificatore, per inviare un
-messaggio su una coda si utilizza la funzione \func{msgsnd}; il suo prototipo
+messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
è:
\begin{functions}
\headdecl{sys/types.h}
\end{itemize*}
La funzione che viene utilizzata per estrarre un messaggio da una coda è
-\func{msgrcv}; il suo prototipo è:
+\funcd{msgrcv}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
\var{fortunefilename} il file da cui leggerle; dopo aver installato
-(\texttt{\small 19--21}) dei manipolatori per gestire l'uscita dal server,
-viene prima controllato (\texttt{\small 22}) il numero di frasi richieste
-abbia senso (cioè sia maggiore di zero), le quali poi (\texttt{\small 23})
-vengono lette nel vettore in memoria con la stessa funzione
-\code{FortuneParse()} usata anche per il server basato sulle fifo.
+(\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
+server, viene prima controllato (\texttt{\small 22}) il numero di frasi
+richieste abbia senso (cioè sia maggiore di zero), le quali poi
+(\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
+funzione \code{FortuneParse()} usata anche per il server basato sulle fifo.
Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
Si noti che il programma può terminare solo grazie ad una interruzione da
-parte di un segnale; in tal caso verrà eseguito il manipolatore
+parte di un segnale; in tal caso verrà eseguito il gestore
\code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
(\texttt{\small 44}) ed ad uscire (\texttt{\small 45}).
semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
permette di creare o ottenere l'identificatore di un insieme di semafori è
-\func{semget}, ed il suo prototipo è:
+\funcd{semget}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
La funzione che permette di effettuare le varie operazioni di controllo sui
semafori (fra le quali, come accennato, è impropriamente compresa anche la
-loro inizializzazione) è \func{semctl}; il suo prototipo è:
+loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
-vengono effettuate con la funzione \func{semop}, il cui prototipo è:
+vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\label{sec:ipc_sysv_shm}
Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
-memoria condivisa. La funzione che permette di ottenerne uno è \func{shmget},
+memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\end{table}
Al solito la funzione che permette di effettuare le operazioni di controllo su
-un segmento di memoria condivisa è \func{shmctl}; il suo prototipo è:
+un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/ipc.h}
\headdecl{sys/shm.h}
gli ultimi due sono delle estensioni previste da Linux.
Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due
-funzioni, la prima è \func{shmat}, che serve ad agganciare un segmento al
+funzioni, la prima è \funcd{shmat}, che serve ad agganciare un segmento al
processo chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di
indirizzi; il suo prototipo è:
\begin{functions}
Una volta che un segmento di memoria condivisa non serve più, si può
sganciarlo esplicitamente dal processo usando l'altra funzione
-dell'interfaccia, \func{shmdt}, il cui prototipo è:
+dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/shm.h}
projects / gapil.git / blobdiff