Newsgroup: it.comp.os.linux.development
Titolo: socket su linux - C++ e KDEVELOP

sto progettando un software che deve gestire una comunicazione abbastanza
pesante tra un client e un server.
La questione principale è che ho programmato sempre in casa microsoft o java
e non sotto linux.
domanda:
esiste un metodo che viene invocato dalle socket solo quando arrivano dati 
sul buffer?
oppure bisogna implementarlo tramite un thread e leggendo sempre tramite 
recv(sock.....) ?
grazie a tutti 

 sul buffer?
man select
Saluti,
The Librarian

 man select
Che mi pare però di dica solo che puoi leggere da un socket, non che ci 
siano dei dati sul socket stesso.
Io userei semplicemente un socket non bloccante.
-- 
Articolo 33 della Costituzione italiana: L'arte e la scienza sono 
libere e libero ne è l'insegnamento

 Io userei semplicemente un socket non bloccante.
Certamente si puo' fare anche in questo modo, pero' non mi sembra
molto elegante come soluzione. Il thread in pratica fa polling sul
socket finche' non arriva qualcosa. IMHO e' meglio un meccanismo di
tipo interrupt.
Saluti,
The Librarian

 
che conferma quello che dice Davide.. un socket che sia stato chiuso 
dall'altro lato, ad esempio, risulta leggibile ma non ci sono dati.
-- 
SF
Facciamo quello per cui siamo stati addestrati, per cui siamo stati cresciuti, 
per cui siamo nati. Niente prigionieri, nessuna pietà. Inizio memorabile.

andrebbe bene se ussassi una soluzione di questo tipo:
se genero un processo che su un ciclo infinito
usasse la recv (bloccante) in un thread che resta quindi in attesa di dati
sarebbe sbagliato?
do{
 recv(sock buffer....)
 //invio dati al buffer principale e invio signal
 //al thread principale per indicare l'arrivo dei dati
}while(1)
il thread andrebbe in wait finchè non ci sono dati sulla socket...
regge una cosa del genere sotto linux?
fondamentalmente mi interessa che regga nella ricezione di una grande mole
di dati
su un singolo canale.

 dall'altro lato, ad esempio, risulta leggibile ma non ci sono dati.
Ok, ora capisco l'obiezione di Davide. Select segnala solo se la read
non e' bloccante e una read che fallisce e' non bloccante. E
certamente bisogna tenerne in conto.
Pero' questo non credo invalidi l'utilita' di select in questo caso
(anche se e' ovviamente progettata per essere utilizzata con piu' di
un fd alla volta).
Saluti,
The Librarian

 grazie a tutti
Premetto che anche io preferisco usare select(2) per questi problemi,
comunque la risposta letterale alla tua domanda che lascia intuire
la gestione dell' evento "ricevuti dati" e' di cercare con google
SIGIO. Consiste nel chiedere al sistema ci mandare al processo
un signal SIGIO alla ricezione di dati su sochets opportunamente
configurate per la gestione dell' IO asincrono.
Definisci un signal handler per SIGIO e con fcntl(2) setti per i
socket che ti interessano l' IO asincrono.
ATTENZIONE!! Tale tecnica e' molto a basso livello e pure sconsigliata
perche' piu' costosa computazionalmente dell' IO sincrono multiplexato
con select(2). Considera che SIGIO non avra' come argomento il socket
disponibile per la lettura, quindi dentro l' handler comunque lo dovrai
scoprire con select su tutti i possibili sockets.
il signal handler verra' eseguito in maniera asincrona al flusso del
quindi dovrai gestire i punti critici bloccando SIGIO. Come detto,
questa tecnica raramente e' da preferire, comunque e' supportata da
Unix/Linux/POSIX.
Ciao
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 regge una cosa del genere sotto linux?
SI... PUO'... FARE!
Francamente non so se inviare un signal al thread principale sia la
scelta migliore, visto che non conosco esattamente tutto lo scenario.
Saluti,
The Librarian

 ha scritto nel messaggio 
news:fq179v$g2$1...@news.newsland.it...

sto provando ad usare un thread e a bloccarlo in attesa sulla recv.
con un loop infinito (ma utilizzando la recv bloccante e quindi il thread va 
in wait).
vediamo come va,
preferisco non toccare troppo a basso livello...

grande...
mi posti la risposta anche con la citazione del mitico Frank....

 regge una cosa del genere sotto linux?
Per fare si può fare, ma per tanti motivi, se riesci a non usare i 
thread è sempre meglio. Sempre che tu non riesca a scrivere codice 
"buono" al primo colpo. Io non ci riesco e fare debug di codice 
multithread è sempre ostico.
Per questo consigliavo un socket non bloccante.
Nell'unico thread dell'applicazione potrebbe esserci un codice simile:
while(true)
{
  //letto qualcosa con la recv?
  //faccio qualcosa
  if( /* devo uscire dal ciclo? */)
     break;
  usleep( /* il tempo necessario */ );


 certamente bisogna tenerne in conto.
Tipicamente se scatta il tuo filedescriptor nella select e ti viene 
restituito 0 da recv() significa "connection closed by foreign host".
L'eccezione e` il caso in cui errno vale EWOULDBLOCK, ma perche` cio` 
succeda devi aver impostato i socket in modalita` non blocking.
Ti suggerisco anch'io un'approccio basato su select piuttosto che su 
socket non bloccante, o peggio, thread.
Magari aggiungi alla select un timeout se nel tuo ciclo devi fare anche 
qualche altra cosa, ovviamente la recv() la fai solo se il tuo 
filedescriptor e` impostato all'uscita della select (il check si fa con 
FD_ISSET).
---
Bye,
  Gabry