[C] Accettare richieste da una pipe

[Ed_Bunker]

Ciao, dovendo realizzare un semplice server che accetti richieste da una pipe ho semplicemente utilizzato una pipe con nome creata dal server stesso, aperta in lettura con l'opzione O_NONBLOCK e poi ho fatto un ciclo del genere:

...
...
while (TRUE)
{
if(read(fd, buffer, MAXBUFFER) > )
{
...
...
...
...
...
}
/*Altrimenti torno all'inizio del ciclo infinito*/
}

E' giusto fare cosi' oppure c'e' un modo per evitare di fare continuamente delle read che restituiscono 0 finche' un qualche client scrive sulla pipe con nome ?! Ad esempio non c'e' la possibilita' di ricevere un segnale quando avviene una scrittura sulla pipe oppure un altro modo cosicche' si possa evitare di sprecare "risorse" ?

thks

[ilsensine]

Puoi vedere se ci sono dati nel pipe con la ioctl FIONREAD (non bloccante) oppure con select o poll (bloccante o con timeout).

nb: una read su un fd non bloccante che non contiene dati non ritorna 0, bensì -1 con errno=EAGAIN.

[Ed_Bunker]

Originariamente inviato da ilsensine
Puoi vedere se ci sono dati nel pipe con la ioctl FIONREAD (non bloccante) oppure con select o poll (bloccante o con timeout).

nb: una read su un fd non bloccante che non contiene dati non ritorna 0, bensì -1 con errno=EAGAIN.

Se non sbaglio il timeout puo' essere impostato anche con la select (Ma a me non interessa). Vorrei che l'attesa fosse indefinita. L'unica cosa di cui ho bisogno e' che il server, appena la pipe e' sta aperta da qualcun altro in scrittura, cominci a fare delle read per leggere le richieste da elaborare.

[ilsensine]

Originariamente inviato da Ed_Bunker
Se non sbaglio il timeout puo' essere impostato anche con la select (Ma a me non interessa).

Infatti mi riferivo ad entrambe

Vorrei che l'attesa fosse indefinita.

Allora perché non usi direttamente una read su pipe bloccante?

L'unica cosa di cui ho bisogno e' che il server, appena la pipe e' sta aperta da qualcun altro in scrittura, cominci a fare delle read per leggere le richieste da elaborare.

La parte interessante del problema è vedere se è possibile notificare al server la semplice "apertura" della pipe, senza che alcun dato sia ancora stato scritto. Non so se con select/poll è possibile, non ho mai provato.
Al di là di questo, credo che una read bloccante faccia al caso tuo no?

[Ed_Bunker]

Originariamente inviato da ilsensine
Infatti mi riferivo ad entrambe

Allora perché non usi direttamente una read su pipe bloccante?

La parte interessante del problema è vedere se è possibile notificare al server la semplice "apertura" della pipe, senza che alcun dato sia ancora stato scritto. Non so se con select/poll è possibile, non ho mai provato.
Al di là di questo, credo che una read bloccante faccia al caso tuo no?

Si la read bloccante andrebbe benissimo. Pensavo, pero', che la read fosse bloccante solo se la pipe era aperta almeno da qualcuno in scrittura e, nonostante questo, non ci fossero dati da leggere. Invece, se io ho aperto la pipe in lettura (con la macro O_NONBLOCK) e nessuno l'ha aperta in scrittura, la read dovrebbe ritornare sempre 0. (Oppure c'e' una "opzione" per rendere la read ugualmente bloccante ?)

[ilsensine]

Puoi cambiare la (a)sincronicità di un fd con qualche ioctl oppure con fcntl, mi sembra.

se io ho aperto la pipe in lettura (con la macro O_NONBLOCK) e nessuno l'ha aperta in scrittura, la read dovrebbe ritornare sempre 0.

ripeto: -1 con errno=EAGAIN, indipendentemente che l'altra parte sia aperta o meno.

Oppure c'e' una "opzione" per rendere la read ugualmente bloccante ?

<OT> con i socket puoi fare il contrario: su un socket _bloccante_ puoi fare una recv non bloccante tramite il flag MSG_DONTWAIT. Non so però se la recv funziona anche su pipe, visto che è specifica dei socket (in teoria tra un socket stream e un pipe non c'è molta differenza; inoltre, un socket PF_UNIX e un pipe sono praticamente la stessa cosa)

[Ed_Bunker]

Leggi QUA ed in particolare:

"... Una volta che si è certi che la fifo di ascolto esiste la procedura di inizializzazione è completata. A questo punto si può chiamare (23) la funzione daemon per far proseguire l'esecuzione del programma in background come demone. Si può quindi procedere (24–33) alla apertura della fifo: si noti che questo viene fatto due volte, prima in lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo principale il caso in cui il server è in ascolto ma non ci sono client che effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo dal capo in lettura, l'esecuzione di read ritorna con zero byte (si ha cioè una condizione di end-of-file).

Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque client non apre a sua volta la fifo nota in scrittura per effettuare la sua richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo. A questo punto il server resta (se non ci sono altri client che stanno effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo stato la funzione read non si bloccherà in attesa di input, ma ritornerà in continuazione, restituendo un end-of-file..."

[ilsensine]

Originariamente inviato da Ed_Bunker
Si ricordi infatti che quando una fifo è aperta solo dal capo in lettura, l'esecuzione di read ritorna con zero byte (si ha cioè una condizione di end-of-file).

Bella questa, non la sapevo.

[Ed_Bunker]

Originariamente inviato da ilsensine
Bella questa, non la sapevo.

E' proprio questo che dicevo prima.