[C]Errore o interrupt in una write()

[echurricane]

Se l'estremo in lettura di una pipe viene chiuso MENTRE la write() sta scrivendo, arriva un segnale SIGPIPE che, se gestito, al ritorno al programma principale farà restituire -1 alla write() settando errno con EINTR.
E' giusto?

E se invece l'estremo di lettura viene chiuso PRIMA della chiamata alla write(), cosa succede? C'è comunque un segnale alla chiamata, oppure la write() fallirà settando errno con EPIPE?

E cosa succede con un socket SOCK_STREAM?

[british]

Se l'estremo in lettura di una pipe viene chiuso MENTRE la write() sta scrivendo, arriva un segnale SIGPIPE che, se gestito, al ritorno al programma principale farà restituire -1 alla write() settando errno con EINTR.
E' giusto?

Si ma credo che errno venga settato a EPIPE, sia che il segnale venga gestito o ignorato.


E se invece l'estremo di lettura viene chiuso PRIMA della chiamata alla write(), cosa succede? C'è comunque un segnale alla chiamata, oppure la write() fallirà settando errno con EPIPE?

come sopra.


E cosa succede con un socket SOCK_STREAM?

Mi pare sia come una pipe, ma non sono sicurissimo che non ci sia qualche altra fregatura in mezzo.

ciao!

[echurricane]

Ti ringrazio, ma vorrei capire meglio.

Se non ci fosse alcun gestore per il segnale SIGPIPE, il processo che lo riceve terminerebbe immediatamente in modo anomalo, senza neppure far terminare la write().
[Almeno credo...]

Se invece il segnale SIGPIPE venisse gestito (o anche esplicitamente ignorato) allora la write() interrotta fallirebbe restituendo -1, ma in teoria non dovrebbe sapere perchè ha fallito, in quanto il segnale di chiusura del canale di comunicazione è arrivato in modalità asincrona; perciò credo che in questo caso errno=EINTR.

Se invece il canale fosse chiuso PRIMA dell'invocazione della write(), allora questa saprebbe già inizialmente che la pipe è chiusa, allora può "semplicemente" fallire con errno=EPIPE.

Comunque, se possibile, vorrei estendere la domanda.
Se stessi scrivendo un server multithread, e stabilissi connessioni TCP con diversi client (e quindi sono sicuro del fatto che il socket esiste), come dovrei comportarmi nel momento in cui una write dovesse fallire perchè il canale non esiste più?
Potrei terminare semplicemente il thread?
D'altronde è un server, inizialmente la comunicazione andava bene e se si è interrotta non posso fare granchè ... visto che devo scrivere anche il client, magari gestirò lì questo tipo di inconvenienti.

[british]

Se non ci fosse alcun gestore per il segnale SIGPIPE, il processo che lo riceve terminerebbe immediatamente in modo anomalo, senza neppure far terminare la write().

esatto.


Se invece il segnale SIGPIPE venisse gestito (o anche esplicitamente ignorato) allora la write() interrotta fallirebbe restituendo -1, ma in teoria non dovrebbe sapere perchè ha fallito, in quanto il segnale di chiusura del canale di comunicazione è arrivato in modalità asincrona; perciò credo che in questo caso errno=EINTR.

Se invece il canale fosse chiuso PRIMA dell'invocazione della write(), allora questa saprebbe già inizialmente che la pipe è chiusa, allora può "semplicemente" fallire con errno=EPIPE.

Sinceramente non saprei, ma leggendo man 2 write al paragrafo Errors
"
EINTR
The call was interrupted by a signal before any data was written; see signal(7).
[...]
EPIPE
fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)
"
mi sembra di capire che in entrambi i casi da te citati venga restituito EPIPE, mentre EINTR sia riservato all'interruzione da parte di tutti gli altri segnali meno SIGPIPE.


Comunque, se possibile, vorrei estendere la domanda.
Se stessi scrivendo un server multithread, e stabilissi connessioni TCP con diversi client (e quindi sono sicuro del fatto che il socket esiste), come dovrei comportarmi nel momento in cui una write dovesse fallire perchè il canale non esiste più?
Potrei terminare semplicemente il thread?
D'altronde è un server, inizialmente la comunicazione andava bene e se si è interrotta non posso fare granchè ... visto che devo scrivere anche il client, magari gestirò lì questo tipo di inconvenienti.

Sembra ragionevole, ma come sempre dipende da "cosa ha senso" nella tua applicazione.

ciao!

[echurricane]

Ancora una volta, grazie!

Comunque credo che il man di Linux e quello di BSD, nonostante siano entrambi POSIX-compliant, siano leggermente differenti.
Io uso un MAC OS X, e il "mio" manuale dice

"
[EINTR] A signal interrupts the write before it could be completed.
[...]
[EPIPE] An attempt is made to write to a pipe that is not open for reading by any process.

[EPIPE] An attempt is made to write to a socket of type SOCK_STREAM that is not connected to a peer socket.
"

che lascerebbe intendere che se la write() inizia e viene interrotta, allora errno=EINTR.

E' possibile che nonostante entrambi i sistemi siano POSIX-compliant, si comportino diversamente?

[british]

"
[EINTR] A signal interrupts the write before it could be completed.
[...]
[EPIPE] An attempt is made to write to a pipe that is not open for reading by any process.

[EPIPE] An attempt is made to write to a socket of type SOCK_STREAM that is not connected to a peer socket.
"

che lascerebbe intendere che se la write() inizia e viene interrotta, allora errno=EINTR.

E' possibile che nonostante entrambi i sistemi siano POSIX-compliant, si comportino diversamente?

mah, io resto dell'interpretazione che questo sia solo un caso particolare in cui il segnale (SIGPIPE) che interrompe la write fa restituire a quest'ultima EPIPE, anzichè EINTR.
Quando ho un attimo mi spulcio per bene lo Stevens e vediamo se dice qualcosa.

ciao!