Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
REDMI Note 17 Pro porta in fascia media una batteria da 8.340 mAh con ricarica HyperCharge a 67W, un display AMOLED da 6,83 pollici capace di picchi di luminosità molto elevati e una struttura certificata TÜV SÜD contro cadute e infiltrazioni d'acqua, il tutto racchiuso in una scocca da 223 grammi. Lo abbiamo provato per diversi giorni tra fotocamera, prestazioni, autonomia e prezzo sul mercato italiano
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra integra un sensore da 1 pollice 8K, ottiche Leica e triplo chip IA. Tra schermo OLED rimovibile, workflow I-Log a 10 bit e stabilizzazione a tre assi, analizziamo le doti tecniche di una gimbal camera pensata per i professionisti
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine porta Logan in un'avventura inedita, violenta e fortemente narrativa, costruita attorno alla sua natura di combattente e al difficile rapporto con il proprio passato. Insomniac Games punta su combattimenti spettacolari, progressione e personalizzazione, inserendo l'azione in un mondo segnato dalla persecuzione dei mutanti. Un viaggio intenso, che alterna mattanza, esplorazione e momenti sorprendentemente emotivi.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 26-12-2011, 18:08   #1
echurricane
Member
 
Iscritto dal: Mar 2011
Messaggi: 30
[C]Errore o interrupt in una write()

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?
echurricane è offline   Rispondi citando il messaggio o parte di esso
Old 27-12-2011, 13:47   #2
british
Member
 
L'Avatar di british
 
Iscritto dal: Sep 2008
Città: Milano
Messaggi: 126
Quote:
Originariamente inviato da echurricane Guarda i messaggi
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.

Quote:
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.

Quote:
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!
british è offline   Rispondi citando il messaggio o parte di esso
Old 27-12-2011, 18:25   #3
echurricane
Member
 
Iscritto dal: Mar 2011
Messaggi: 30
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.
echurricane è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2011, 15:09   #4
british
Member
 
L'Avatar di british
 
Iscritto dal: Sep 2008
Città: Milano
Messaggi: 126
Quote:
Originariamente inviato da echurricane Guarda i messaggi
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.

Quote:
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.

Quote:
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!
british è offline   Rispondi citando il messaggio o parte di esso
Old 28-12-2011, 20:51   #5
echurricane
Member
 
Iscritto dal: Mar 2011
Messaggi: 30
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?
echurricane è offline   Rispondi citando il messaggio o parte di esso
Old 30-12-2011, 12:46   #6
british
Member
 
L'Avatar di british
 
Iscritto dal: Sep 2008
Città: Milano
Messaggi: 126
Quote:
Originariamente inviato da echurricane Guarda i messaggi
"
[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!
british è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce Recensione REDMI Note 17 Pro: il midrange con ba...
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema Insta360 Luna Ultra: la potenza del sensore da 1...
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa Marvel's Wolverine, la recensione: Logan torna p...
DJI Romo 2: tante novità lo rendono un robot completo DJI Romo 2: tante novità lo rendono un ro...
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED Sony Bravia 9 II: il True RGB alla prova, dove l...
Maserati, si concretizza la pista cinese...
Corea del Sud preoccupata: le cinesi YMT...
Se ne vendono 3000 al mese su Amazon: Sm...
Sedie gaming ergonomiche su Amazon: SONG...
Criptovalute, il Senato USA blocca il Cl...
Samsung Galaxy S26 FE a 635€ con coupon ...
Tesla porta il Cybercab in Cina, ma solo...
I modelli di OpenAI mentono e si nascond...
Rivoluzione in arrivo per il Game Pass? ...
Lefant V1 torna a 99€: scopa elettrica s...
L'FBI sequestra NightmareStresser: centi...
Copilot sparisce da Outlook classico dop...
DEEPOWER Fat Bike 20'': la e-bike con ba...
Sam Altman a Dreamforce 2026, OpenAI ver...
Volkswagen ID.3 GTI: la GTI elettrica pi...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 09:51.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v