Torna indietro   Hardware Upgrade Forum > Software > Programmazione

MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi
MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi
Abbiamo provato MSI PRO MAX EDGE AI+, un mini-PC professionale progettato per eseguire modelli di intelligenza artificiale in locale, senza dipendere dal cloud. Il sistema abbina il processore AMD Ryzen AI Max+ 395, 128 GB di memoria unificata e un telaio in alluminio da appena 4 litri, con l'obiettivo di offrire capacità di elaborazione elevate in un formato compatto.
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista
Il nuovo top di gamma vivo punta su un comparto fotografico particolarmente articolato, con un teleobiettivo da 200 megapixel e teleconvertitori esterni capaci di arrivare a 400 mm equivalenti. Lo abbiamo provato a Tenerife, mettendo alla prova fotocamere, prestazioni, autonomia e accessori. Ecco come si è comportato.
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà
Un mondo affollato e vivo, personaggi destinati a sparire a fine test e nessuno a inseguire l'oggetto giusto. Beta e stress test di World of Warcraft: Forever hanno fatto emergere un roleplay spontaneo, tra danze a Goldshire e code ordinate ai PNG
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 26-12-2011, 19: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, 14: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, 19: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, 16: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, 21: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, 13: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


MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB...
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista Recensione vivo X500 Pro Max: la fotografia mobi...
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà WoW Forever: la beta è stato uno dei mome...
Oracle AI World 2026: in Europa prima la sovranità, poi la sicurezza e solo dopo l'IA Oracle AI World 2026: in Europa prima la sovrani...
DS N°7 E-Tense: il SUV premium made in Melfi che punta su autonomia e comfort DS N°7 E-Tense: il SUV premium made in Melfi...
Sempre più applicazioni ottimizza...
Skullcandy Icon, prezzo quasi dimezzato ...
WhatsApp cambia le regole dei gruppi: 4 ...
Brave finisce in tribunale: avrebbe ruba...
Electrolux, notte di trattative al Mimit...
LG OLED C6 da 77 pollici, il prezzo scen...
Apple avvisa 99 Paesi: spyware mercenari...
Zenbook S Con Core 5 Ultra e schermo da ...
Prendere appunti con dito, penna e AI: c...
Itch.io, filtro "No AI": i giochi visibi...
Microsoft conferma: il nuovo speed test ...
Il capo può far leggere a Claude le chat...
L'AI fa volare AMD, ma c'è un set...
Le scuole statunitensi che rifiutano Gem...
WhatsApp, addio al supporto su iPhone e ...
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: 10:15.


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