X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=1888d4af87668637cbefb553af564e55d7b12d4d;hp=3baa2b83eae6a31528f59df05163fead6ff22d18;hb=70860564e1de946ab8d681bb41c601ba77721709;hpb=22e01eeebd2d386a8a992cba0fdaf2d73f5ff217 diff --git a/ipc.tex b/ipc.tex index 3baa2b8..1888d4a 100644 --- a/ipc.tex +++ b/ipc.tex @@ -1,6 +1,6 @@ %% ipc.tex %% -%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2007 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", @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{La comunicazione fra processi} \label{cha:IPC} @@ -707,10 +708,9 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens, fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle fifo non è adatta a risolvere questo tipo di problemi, che possono essere -affrontati in maniera più semplice ed efficace o usando i -\textit{socket}\index{socket} (che tratteremo in dettaglio a partire da -cap.~\ref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione -diversi, come quelli che esamineremo in seguito. +affrontati in maniera più semplice ed efficace o usando i socket (che +tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo +a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito. @@ -720,40 +720,39 @@ diversi, come quelli che esamineremo in seguito. Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento -dei \textit{socket}\index{socket} in cap.~\ref{cha:socket_intro},\footnote{si - tratta comunque di 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 +dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di + 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 \textit{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} è +(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\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}, -con la sola differenza è che in questo caso il flusso dei dati può essere -effettuato in entrambe le direzioni. Il prototipo della funzione è: +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 è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/socket.h} \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])} - Crea una coppia di socket\index{socket} connessi fra loro. + Crea una coppia di socket connessi fra loro. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EAFNOSUPPORT}] I socket\index{socket} locali non sono - supportati. + \item[\errcode{EAFNOSUPPORT}] I socket locali non sono supportati. \item[\errcode{EPROTONOSUPPORT}] Il protocollo specificato non è supportato. \item[\errcode{EOPNOTSUPP}] Il protocollo specificato non supporta la - creazione di coppie di socket\index{socket}. + creazione di coppie di socket. \end{errlist} ed inoltre \errval{EMFILE}, \errval{EFAULT}. } @@ -762,19 +761,19 @@ effettuato in entrambe le direzioni. Il prototipo della funzione La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di loro: quello che si scrive su uno di essi sarà ripresentato in input sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e -\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi +\param{protocol} derivano dall'interfaccia dei socket (vedi sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per connettere i due descrittori, ma in questo caso i soli valori validi che possono essere specificati sono rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}. L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe} -può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei -socket\index{socket} locali in generale) permette di trasmettere attraverso le -linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da -un processo ad un altro un file descriptor, con una sorta di duplicazione -dello stesso non all'interno di uno stesso processo, ma fra processi distinti -(torneremo su questa funzionalità in sez.~\ref{sec:sock_fd_passing}). +può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket +locali in generale) permette di trasmettere attraverso le linea non solo dei +dati, ma anche dei file descriptor: si può cioè passare da un processo ad un +altro un file descriptor, con una sorta di duplicazione dello stesso non +all'interno di uno stesso processo, ma fra processi distinti (torneremo su +questa funzionalità in sez.~\ref{sec:sock_fd_passing}). \section{Il sistema di comunicazione fra processi di System V} @@ -979,7 +978,7 @@ a differenza di quanto avviene per i permessi dei file, fallire in uno dei passi elencati non comporta il fallimento dell'accesso. Un'ulteriore differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC il valore di \var{umask} (si ricordi quanto esposto in -sez.~\ref{sec:file_umask}) non ha alcun significato. +sez.~\ref{sec:file_perm_management}) non ha alcun significato. \subsection{Gli identificatori ed il loro utilizzo} @@ -1639,7 +1638,7 @@ passo (\texttt{\small 17}) prima di uscire messaggio ricevuto. Proviamo allora il nostro nuovo sistema, al solito occorre definire -\code{LD\_LIBRAY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di +\code{LD\_LIBRARY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di che, in maniera del tutto analoga a quanto fatto con il programma che usa le fifo, potremo far partire il server con: \begin{verbatim} @@ -2316,7 +2315,7 @@ controllare il valore dei mutex prima di proseguire in una operazione di sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica. Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere un'interfaccia analoga a quella appena illustrata, senza incorrere in questi -problemi, usando il file locking\index{file!locking}. +problemi, usando il \index{file!locking} \textit{file locking}. \subsection{Memoria condivisa} @@ -2506,20 +2505,20 @@ corrispondente comportamento della funzione, sono i seguenti: \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o il creatore del segmento, oppure l'amministratore. Compiuta l'operazione aggiorna anche il valore del campo \var{shm\_ctime}. -\item[\const{SHM\_LOCK}] Abilita il \textit{memory - locking}\itindex{memory~locking}\footnote{impedisce cioè che la memoria - usata per il segmento venga salvata su disco dal meccanismo della memoria - virtuale\index{memoria~virtuale}; si ricordi quanto trattato in +\item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory + locking}\footnote{impedisce cioè che la memoria usata per il segmento + venga salvata su disco dal meccanismo della \index{memoria~virtuale} + memoria virtuale; si ricordi quanto trattato in sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo l'amministratore può utilizzare questo comando. -\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory - locking}\itindex{memory~locking} sul segmento di memoria condivisa. Solo +\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} + \itindex{memory~locking} sul segmento di memoria condivisa. Solo l'amministratore può utilizzare questo comando. \end{basedescript} i primi tre comandi sono gli stessi già visti anche per le code di messaggi e gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche previste da Linux, che permettono di abilitare e disabilitare il meccanismo -della memoria virtuale\index{memoria~virtuale} per il segmento. +della memoria virtuale \index{memoria~virtuale} per il segmento. L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT} e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura @@ -2558,7 +2557,7 @@ direttamente, la situazione dopo l'esecuzione di \func{shmat} fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In particolare l'indirizzo finale del segmento dati (quello impostato da -\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk_alloca}) non viene influenzato. +\func{brk}, vedi sez.~\ref{sec:proc_mem_alloc}) non viene influenzato. Si tenga presente infine che la funzione ha successo anche se il segmento è stato marcato per la cancellazione. @@ -2707,7 +2706,7 @@ chiave ed il puntatore associati al segmento di memoria condivisa, prima lo sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è la chiamata a \func{shmdt} per sganciare il segmento, restituendo (\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo -(\texttt{\small 41}) è utilizzare \func{shmget} per ottenre l'identificatore +(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore associato al segmento data la chiave \var{key}. Al solito si restituisce un valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va bene si conclude restituendo un valore nullo. @@ -2770,7 +2769,7 @@ Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da riga di comando (che si limitano alla eventuale stampa di un messaggio di aiuto a video ed all'impostazione della durata dell'intervallo con cui viene ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small - 20--23}) che sia stato specificato l'argoemnto necessario contenente il nome + 20--23}) che sia stato specificato l'argomento necessario contenente il nome della directory da tenere sotto controllo, senza il quale esce immediatamente con un messaggio di errore. @@ -3012,11 +3011,11 @@ incorrere nelle complicazioni introdotte dal \textit{SysV IPC}. In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi hanno delle caratteristiche ulteriori, consentendo una classificazione dei messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che -sono impossibili da ottenere con le pipe e i socket\index{socket} di -\func{socketpair}. A queste esigenze però si può comunque ovviare in maniera -diversa con un uso combinato della memoria condivisa e dei meccanismi di -sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è -relativamente poco diffuso. +sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A +queste esigenze però si può comunque ovviare in maniera diversa con un uso +combinato della memoria condivisa e dei meccanismi di sincronizzazione, per +cui alla fine l'uso delle code di messaggi classiche è relativamente poco +diffuso. \subsection{I \textsl{file di lock}} \label{sec:ipc_file_lock} @@ -3037,13 +3036,13 @@ caratteristica della funzione \func{open} (illustrata in sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo standard POSIX.1, ciò non toglie che in alcune implementazioni questa tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si - è comunque soggetti alla possibilità di una \textit{race - condition}\itindex{race~condition}.} che essa ritorni un errore quando -usata con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la -creazione di un \textsl{file di lock} può essere eseguita atomicamente, il -processo che crea il file con successo si può considerare come titolare del -lock (e della risorsa ad esso associata) mentre il rilascio si può eseguire -con una chiamata ad \func{unlink}. + è comunque soggetti alla possibilità di una \itindex{race~condition} + \textit{race condition}.} che essa ritorni un errore quando usata con i +flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un +\textsl{file di lock} può essere eseguita atomicamente, il processo che crea +il file con successo si può considerare come titolare del lock (e della +risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata +ad \func{unlink}. Un esempio dell'uso di questa funzione è mostrato dalle funzioni \func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock} @@ -3124,30 +3123,31 @@ leggermente pi \end{minipage} \normalsize \caption{Il codice delle funzioni che permettono per la gestione dei - \textit{mutex} con il file locking\index{file!locking}.} + \textit{mutex} con il \index{file!locking} \textit{file locking}.} \label{fig:ipc_flock_mutex} \end{figure} Il codice delle varie funzioni usate per implementare un mutex utilizzando il -file locking\index{file!locking} è riportato in fig.~\ref{fig:ipc_flock_mutex}; -si è mantenuta volutamente una struttura analoga alle precedenti funzioni che -usano i semafori, anche se le due interfacce non possono essere completamente -equivalenti, specie per quanto riguarda la rimozione del mutex. +\textit{file locking} \index{file!locking} è riportato in +fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura +analoga alle precedenti funzioni che usano i semafori, anche se le due +interfacce non possono essere completamente equivalenti, specie per quanto +riguarda la rimozione del mutex. La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a creare il mutex; la funzione è estremamente semplice, e si limita (\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il -file che sarà usato per il successivo file locking, assicurandosi che non -esista già (nel qual caso segnala un errore); poi restituisce il file +file che sarà usato per il successivo \textit{file locking}, assicurandosi che +non esista già (nel qual caso segnala un errore); poi restituisce il file descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il mutex. La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la precedente, è stata definita per mantenere una analogia con la corrispondente funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad -aprire il file da usare per il file locking, solo che in questo caso le -opzioni di \func{open} sono tali che il file in questione deve esistere di -già. +aprire il file da usare per il \index{file!locking} \textit{file locking}, +solo che in questo caso le opzioni di \func{open} sono tali che il file in +questione deve esistere di già. La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza @@ -3162,9 +3162,10 @@ La quarta funzione (\texttt{\small 24--34}) rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna -chiamata a \func{fcntl}. Avendo usato il file locking in semantica POSIX (si -riveda quanto detto sez.~\ref{sec:file_posix_lock}) solo il processo che ha -precedentemente eseguito il lock può sbloccare il mutex. +chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file + locking} in semantica POSIX (si riveda quanto detto +sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente +eseguito il lock può sbloccare il mutex. La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a cancellare il mutex. Anche questa funzione è stata definita per mantenere una @@ -3318,7 +3319,7 @@ trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc} {\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In generale, come le corrispettive del SysV IPC, le code di messaggi sono poco -usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono +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 mutex e memoria condivisa con tutta la flessibilità che occorre. @@ -3485,7 +3486,7 @@ Rimuove una coda di messaggi. Anche in questo caso il comportamento della funzione è analogo a quello di \func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa - direttamente \func{unlink}.} la funzione rimove la coda \param{name}, così + direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così che una successiva chiamata a \func{mq\_open} fallisce o crea una coda diversa. @@ -3833,10 +3834,10 @@ La funzione apre un segmento di memoria condivisa identificato dal nome \param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo nome può essere specificato in forma standard solo facendolo iniziare per \file{/} e senza ulteriori \file{/}, Linux supporta comunque nomi generici, che -verranno intepretati prendendo come radice \file{/dev/shm}.\footnote{occorre +verranno interpretati prendendo come radice \file{/dev/shm}.\footnote{occorre pertanto evitare di specificare qualcosa del tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo comporta, da parte delle funzioni - di libereria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.} + di libreria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.} 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 @@ -3953,8 +3954,58 @@ cancellare un segmento di memoria condivisa. Dato che al contrario di quanto avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink}, -retituendo al chiamante il valore di ritorno. - +restituendo al chiamante il valore di ritorno. + + +% LocalWords: like fifo System POSIX RPC Calls Common Object Request Brocker +% LocalWords: Architecture descriptor kernel unistd int filedes errno EMFILE +% LocalWords: ENFILE EFAULT BUF sez fig fork Stevens siblings EOF read SIGPIPE +% LocalWords: EPIPE shell CGI Gateway Interface HTML JPEG URL mime type gs dup +% LocalWords: barcode PostScript race condition stream BarCodePage WriteMess +% LocalWords: size PS switch wait popen pclose stdio const char command NULL +% LocalWords: EINVAL cap fully buffered Ghostscript l'Encapsulated epstopsf of +% LocalWords: PDF EPS lseek ESPIPE PPM Portable PixMap format pnmcrop PNG pnm +% LocalWords: pnmmargin png BarCode inode filesystem l'inode mknod mkfifo RDWR +% LocalWords: ENXIO deadlock client reinviate fortunes fortunefilename daemon +% LocalWords: FortuneServer FortuneParse FortuneClient pid libgapil LD +% LocalWords: PATH linker pathname ps tmp killall fortuned crash socket domain +% LocalWords: socketpair BSD sys protocol sv EAFNOSUPPORT EPROTONOSUPPORT AF +% LocalWords: EOPNOTSUPP SOCK SysV IPC Process Comunication ipc perm key exec +% LocalWords: header ftok proj stat libc SunOS glibc XPG dell'inode number uid +% LocalWords: cuid cgid gid tab MSG shift group umask seq MSGMNI SEMMNI SHMMNI +% LocalWords: shmmni msgmni sem sysctl IPCMNI IPCTestId msgget EACCES EEXIST +% LocalWords: CREAT EXCL EIDRM ENOENT ENOSPC ENOMEM novo proc MSGMAX msgmax ds +% LocalWords: MSGMNB msgmnb linked list msqid msgid linux msg qnum lspid lrpid +% LocalWords: rtime ctime qbytes first last cbytes msgctl semctl shmctl ioctl +% LocalWords: cmd struct buf EPERM RMID msgsnd msgbuf msgp msgsz msgflg EAGAIN +% LocalWords: NOWAIT EINTR mtype mtext long message sizeof LENGTH ts sleep BIG +% LocalWords: msgrcv ssize msgtyp NOERROR EXCEPT ENOMSG multiplexing select ls +% LocalWords: poll polling queue MQFortuneServer write init HandSIGTERM +% LocalWords: MQFortuneClient mqfortuned mutex risorse' inter semaphore semget +% LocalWords: nsems SEMMNS SEMMSL semid otime semval sempid semncnt semzcnt nr +% LocalWords: SEMVMX SEMOPM semop SEMMNU SEMUME SEMAEM semnum union semun arg +% LocalWords: ERANGE SETALL SETVAL GETALL array GETNCNT GETPID GETVAL GETZCNT +% LocalWords: sembuf sops unsigned nsops UNDO flg nsop num undo pending semadj +% LocalWords: sleeper scheduler running next semundo MutexCreate semunion lock +% LocalWords: MutexFind wrapper MutexRead MutexLock MutexUnlock unlock locking +% LocalWords: MutexRemove shmget SHMALL SHMMAX SHMMIN shmid shm segsz atime FD +% 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: 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: SHARED ANONYMOUS thread patch names strace system call userid Di +% LocalWords: groupid Michal Wronski Krzysztof Benedyczak wrona posix mqueue +% LocalWords: lmqueue gcc mount mqd name oflag attr maxmsg msgsize receive ptr +% LocalWords: send WRONLY NONBLOCK close mqdes EBADF getattr setattr mqstat +% LocalWords: omqstat curmsgs flags timedsend len prio timespec abs EMSGSIZE +% LocalWords: ETIMEDOUT timedreceive getaddr notify sigevent notification l'I +% 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 %%% Local Variables: