Newsgroup: it.comp.lang.c
Titolo: socket e select

Salve gente! Buon ponte di S. Ambrogio, per coloro che stanno dalle
parti di Milano come il sottoscritto :-)
Dunque, devo fare un progetto per un esame usando le socket, solo che ho
il problema dell'I/O asincrono, ossia piu' processi e piu' socket da
gestire con corrispondenti operazioni di read/write. Ho visto che per
gestire questa situazione si usa la system call select(), solo che non
ho capito come si usa. C'e' nessuno che sa spiegarmi con semplici esempi
come fare per usare socket non bloccanti oppure con timeout? Ho un paio
di tutorial ma li ho trovati un po' criptici o eccessivamente
superficiali...
Gia' che ci sono un altra domanda: per avere memoria condivisa tra due
processi, conosco la vfork(), esistono altri metodi?
Uso Linux e gcc.
Grazie per l'attenzione e le eventuali risposte.
-- 
 Ciao, Luca.
 Reply to 
luca....@tiscalinet.it


Potresti provare con "man mmap".
Comunque visto che i sistemi
unix-like sono generalmente basati sul modello "a scambio di messaggi",
credo che la cosa migliore per poter avere memoria condivisa sia quella
di installare una libreria per il multithreading (tipo PThread che dovresti
poter trovare in rete).
In alcuni casi si puo` simulare un sistema a memoria condivisa con
costrutti tipici dei sistemi a scambio di messaggi. Ho personalmente visto
alcune
implementazioni di pseudo-semafori realizzate con send e recv.
Una attesa sulla recv bloccante simulava
la wait su un semaforo, una send simulava la signal. Comunque se sei
all'inizio e stai cercando di capire come funziona la programmazione
concorrente forse  non e` bene complicare subito le cose (nel caso di
semafori
realizzati con primitive tipiche di sistemi a scambio di messaggi si stava
tentando di implementare un simulatore per un S.O. distribuito a spazio
singolo, cioe` in cui ogni processo nella rete condividesse lo stesso
spazio
di memoria di tutti gli altri processi nella rete, indipendentemente dalla
macchina
su cui girava).
Marco Guidi

 poter trovare in rete).
Il fatto e' che il sorgente devo _portarlo_ (in tutti i sensi) su una
macchina Unix-HP, ossia quello che abbiamo in laboratorio
Per la comunicazione tra processi volevo evitare di dover usare una
pipe() ( a proposito, si puo' fare una read non bloccante su una pipe?
penso di si, dovrebbe essere come per le socket, + o - ) per scambiarsi
informazioni, anche perche' risulterebbe eccessivamente complicato
gestire la dimensione dell'informazione trasmessa, in quanto di
lunghezza variabile.
Grazie ancora.


 lunghezza variabile.
Questa non l'ho capita molto. Cioe` che differenza c'e` rispetto al
caso "socket" ?


Scusa, ma potresti mandarmi in privato la risposta al mio secondo post:
nescape 4.7 mi da qualche problema e non mi scarica tutti i msg dei ng,
non so per quale motivo.
Grazie.


 
In genere quando ho usato le socket, anche se in modo molto semplice
per pura curiosita', usavo unita' di dati di dimensioni costanti, che
so', un buffer di 1K. Con le pipe i due processi erano
"sincronizzati", quindi la dimensione dei dati da leggere/scrivere era
variabile ma nota. Con le socket nel mio progetto devo usare una
dimensione dati variabile e i processi non sanno a priori quale sara'
questa dimensione. Devo inventarmi un bel protocollo per comunicare la
dimensione dei dati e l'interpretazioni di questi: non eccessivamente
complicato ma interessante.



In questo caso pero` il problema della dimensione variabile dei dati
rimarrebbe anche usando le pipe (cioe` se la dimensione dei dati e` variabile
e non si conosce la massima dimensione che potranno avere, si dovrebbe
studiare anche con le pipe un protocollo di comunicazione).
Normalmente la differenza principale tra socket e pipe e` data dal
fatto che le pipe consentono la comunicazione solo tra processi che
risiedono sulla stessa macchina.
Marco Guidi

 risiedono sulla stessa macchina.
Si', hai ragione, non so per quale motivo pensavo che ci potessero
essere delle differenze: una volta creata la socket e usando il TCP,
e' come usare una pipe tra due processi...
