Newsgroup: it.comp.os.linux.development
Titolo: problemi con socket

Ciao a tutti,
Avrei un problema.
Ho una applicazione Clent/Server.
-	Il client si connette
-	Il server fa tutte le operazioni del caso e comincia ad inviare
	pacchetti
Le situazioni anomale che si verificano sono 2.
1) se mando in esecuzione l'applicazione client senza debug non 
riceve 		   niente o solo un pacchetto.
    Alle volte da il messaggio
		"program received signal SIGINT, interrupt".
2) Lo stesso messaggio che da dopo un bel po che lo avvio in modalità
    debug (mettendomi in beak sulla read da socket) con la differenza che
    però qualche messaggio in più lo legge .....
Sapete dirmi se stò trascurando qualche aspetto ?
Dimenticavo, chi fa la lettura da socket è un thread che viene attivato
dal main.
Ciao e Grazie.


Non credi che se non vediamo il programma abbiamo ben poco da dirti?
Ciao, Fabio
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Ciao e Grazie.

Il sorgente č :
la funzione "mia_funzione" viene chiamata all'interno di un ciclo che
preleva i messaggi  :
int  main (...)
{
   int error;
   Connettiti(...);
   while(1)
   {
     error = mia_funzione(sock, ....);
     if(!status)
     /* fai qualche cosa ...*/
     sleep(...);
   }
   ChiudiConnessione(...);
}
______________________________________________________
int  mia_funzione(sock, ....)
{
   status = mia_tcp_receive (sock, buf, &len);
   if (status != 0)
     return(0);
   else
     if (len > 0)
     {		
       sts_msg = process(buf);
       if(sts_msg)
         ....
     }
     else
       return(0);
......
}
______________________________________________________

Ciao Paolo,
è proprio vera una cosa, quando non si conosce un
argomento si tende a dire caz....
il problema l'ho risolto adesso non ho tempo ma domani
vi scrivo quale era l'errore.
I thread sono uno dei meccanismi fondametali dei modermi
SO. come fai a dire certe cose ?
ciao e buon lavoro.

 SO. come fai a dire certe cose ?
Secondo me, che non c'entro niente, Paolo ha ragione.
I thread vanno molto di moda, troppo.
Vengono usati a sproposito, piu' che altro per mettere ordine e "separare i
compiti"
nel programma. Ma  mettere ordine significa progettare in modo ordinato.
Un thread dovrebbe soddisfare 3 requisiti:
  1) l'elaborazione e' pesante, dove per pesante si intende che il tempo
necessario per eseguirla
     non e' tollerabile dal resto del programma, nel suo contesto.
2) l'elaborazione non e' interrompibile (per esempio una syscall non
interrompibile
o una funzione di una libreria di compressione, non interrompibile)
3) lo scambio di dati con il resto del programma avviene alla fine ed
all'inizio dell'elaborazione,
per passare i parametri e raccogliere il risultato.
in genere invece accade, come nel tuo esempio:
1) che le funzioni per lavorare sui socket sono "anche" asincrone e non
bloccanti (volendo),
quindi non c'e' bisogna di un thread "perche' la read si blocca"
2) lo scambio dati tra thread e programma e' continuo (messaggi
ricevuti-messaggi inviati) quindi
si impone un accesso tramite mutex ai dati condivisi.
L'accesso tramite mutex, quando e' fatto spesso, vanifica il parallelismo
del thread perche' o il programma
e' fermo ad aspettare il thread o viceversa.
Inoltre il minimo baco sull'accesso ai dati condivisi si traduce in un debug
molto difficile.
Inoltre usando in modo asincrono le funzioni sui socket, puoi controllare in
modo agevole
il timeout della tua "conversazione". Altrimenti, devi andare giu' di alarm
nel thread per schiodarti da una read
che non legge più .
Ciao.

 ciao Marco, buon Lavoro
ciao

 (uso solo printf!),
oddio, non che il debug a suon di printf sia molto professionale.... :-)


Penso che con il post precedente Paolo P. intendesse dire che ovunque i
thread non siano effettivamente *necessari* e' meglio evitarne l'uso
perche' aggiungono una dose notevole di complessita' da gestire.
Ovviamente IMHO
ciao
-- 
Alberto

 requisiti, anche temporali, te li riparmio).
Ovvio che ci sono casi in cui sono necessari, ma gestire 1000 
periferiche con 1000 thread mi sembra comunque pericoloso :)
Ad esempio i tempi di una pthread_join() in quei casi possono essere 
altissimi con kernel precedenti al 2.6.x.
Bye,
  Gabry

> oddio, non che il debug a suon di printf sia molto professionale.... :-)
trovo gdb troppo macchinoso..