[C] Idea per ciclo di attesa

[Eddie1985]

Salve a tutti
dunque il problema che ho è questo: in un programma scritto in C che deve girare su un sistema Unix-like, devo comprimere alcuni file (non so quanti siano questi file e che dimensione abbiano), quindi devo fare altre operazioni che riguardano l'archivio compresso.
Ora il fatto è questo: mi servirebbe un ciclo di attesa che attenda la fine della compressione, in modo da non utilizzare l'archivio compresso che non è ancora stato totalmente compresso :D
Qualcuno ha qualche idea?

[tecno789]

Salve a tutti
dunque il problema che ho è questo: in un programma scritto in C che deve girare su un sistema Unix-like, devo comprimere alcuni file (non so quanti siano questi file e che dimensione abbiano), quindi devo fare altre operazioni che riguardano l'archivio compresso.
Ora il fatto è questo: mi servirebbe un ciclo di attesa che attenda la fine della compressione, in modo da non utilizzare l'archivio compresso che non è ancora stato totalmente compresso :D
Qualcuno ha qualche idea?

ciao! bel programmino, che algoritmo di compressione hai utilizzato? sarei curioso anche io di implementarlo uno, ma la compressione proprio non mi viene...

comunque rispondendo...potresti fare un file temporaneo, così da non fare neanche il ciclo..alla fine del processo di compressione lo copi e alla fine avrai solo quest'ultimo salvato sull'hd, mentre il file tmp sarà cancellato.

[Eddie1985]

ciao! bel programmino, che algoritmo di compressione hai utilizzato? sarei curioso anche io di implementarlo uno, ma la compressione proprio non mi viene...

l'utente può scegliere se utilizzare il compressore bzip2 oppure gnuzip....non penso sia semplice inventare un nuovo algoritmo di compressione, se è questo che volevi fare :rolleyes:


comunque rispondendo...potresti fare un file temporaneo, così da non fare neanche il ciclo..alla fine del processo di compressione lo copi e alla fine avrai solo quest'ultimo salvato sull'hd, mentre il file tmp sarà cancellato.

mi sa che non ho spiegato bene il mio problema :D
con la tua soluzione il problema che avevo ce l'ho lo stesso! non saprei quando ricopiare il file temporaneo, perchè non so a priori quando terminerà la compressione! potrei mettere subito dopo l'inizio della compressione una sleep di un minuto, ma se la compressione dovesse durare di più? oppure se dovesse durare solo 2 secondi? capisci il problema è come poter verificare se la compressione è terminata oppure no

[tecno789]

l'utente può scegliere se utilizzare il compressore bzip2 oppure gnuzip....non penso sia semplice inventare un nuovo algoritmo di compressione, se è questo che volevi fare :rolleyes:




mi sa che non ho spiegato bene il mio problema :D
con la tua soluzione il problema che avevo ce l'ho lo stesso! non saprei quando ricopiare il file temporaneo, perchè non so a priori quando terminerà la compressione! potrei mettere subito dopo l'inizio della compressione una sleep di un minuto, ma se la compressione dovesse durare di più? oppure se dovesse durare solo 2 secondi? capisci il problema è come poter verificare se la compressione è terminata oppure no

capisco scusami allora....
comunque magari in pvt mi spieghi come hai fatto che mi interessa per favore?

ma se metti uno sleep in base alla dimensione del file??

[starfred]

Ciao, se usi la system(), essa è bloccante, quindi se sei in monothread non ci son problemi. Se sei in multithread oppure se mandi il programma di compressione in bg allora è più complesso.

[Eddie1985]

comunque magari in pvt mi spieghi come hai fatto che mi interessa per favore?

ho fatto con una fork, e poi con una execlp....cmq non è niente di particolarmente complicato, se googleggi un pò dovresti riuscirci (nel caso contattami)


ma se metti uno sleep in base alla dimensione del file??

il problema che cercavo di spiegare è quello, non so a priori la dimensione del file, perchè esso deve essere creato :rolleyes:


Ciao, se usi la system(), essa è bloccante, quindi se sei in monothread non ci son problemi. Se sei in multithread oppure se mandi il programma di compressione in bg allora è più complesso.

uso fork + execlp che immagino sia la stessa cosa che usare la system....ad ogni modo sono in multithread, avevo dimenticato di scriverlo

[tecno789]

ho fatto con una fork, e poi con una execlp....cmq non è niente di particolarmente complicato, se googleggi un pò dovresti riuscirci (nel caso contattami)


scusami stai facendo un programma con licenza?
è troppo se ti chiedo di passarmi il sorgente? perchè non riesco a capire come implementare la conversione! premetto che è da un pò che non riesco a farlo. Mi accontenterei anche di farlo in single-thread visto che le fork non le ho ancora fatte per bene!

[Eddie1985]

perchè non riesco a capire come implementare la conversione! premetto che è da un pò che non riesco a farlo. Mi accontenterei anche di farlo in single-thread visto che le fork non le ho ancora fatte per bene!


scusa cosa è che non riesci ad implementare precisamente? devi semplicemente fare una cosa del genere:

int ret = fork ();
if (ret = 0) {
execlp ("tar", "tar", nome_archivio, NULL);
....
}

[tecno789]

scusa cosa è che non riesci ad implementare precisamente? devi semplicemente fare una cosa del genere:

int ret = fork ();
if (ret = 0) {
execlp ("tar", "tar", nome_archivio, NULL);
....
}

scusami vorresti dire che execlp ti fa la conversione direttamente? ma in che libreria è presente quella funzione??

[Eddie1985]

scusami prima del nome dell'archivio, se intendi usare gnuzip, anche "-czf" , se usi bzip2 qualcosa di simile (dai un bel man tar :) )

[Eddie1985]

ok anche man execl .... :D

[starfred]

Non sei in multithread, sei in multiprocesso.
Devi far attendere al padre la terminazione del figlio. Quindi basta una wait() nel padre. Attenzione alla execlp ed alle exec in generale, tutto ciò che scrivi dopo NON può e NON deve essere eseguito.

[tecno789]

ok anche man execl .... :D

il man cosa fa?

[Tommo]

Ti serve semplicemente di far partire la decompressione su un nuovo thread, che "possiede" un bool che è sempre false finchè non ha finito.

Poi nel thread principale metti


pthread_start( thread, decompress, file );

while( !decompressionHasFinished )
{
//anima la gui, fai quello che ti serve di fare
}

pthread_join( thread );


Quel while può anche essere il "main loop" del programma, quello che conta è che lanci la decompressione su un secondo thread e aspetti così che finisca (o con qualcosa di più complicato tipo una Condition o un pthread_mutex_trylock()).
Il multiprocesso non ti serve! :D
E' importante non usare wait() (nel caso del processo) o join() (nel caso del thread) subito, perchè altrimenti il primo thread si blocca in attesa del secondo... e in pratica hai un thread solo.

[Eddie1985]

Non sei in multithread, sei in multiprocesso.

il programma che devo scrivere (anzi che ho scritto) è multithread....puoi spiegarti meglio?

Devi far attendere al padre la terminazione del figlio. Quindi basta una wait() nel padre. Attenzione alla execlp ed alle exec in generale, tutto ciò che scrivi dopo NON può e NON deve essere eseguito.

ok, quindi quando devo inserire la wait() ? dopo la fork prima di execl? :confused:


il man cosa fa?

seh vabbè.........

[tecno789]

seh vabbè.........

scusami ma man serve solo a vedere il manuale o sbaglio? non e' una funzione...

[starfred]

Un conto sono i processi (diverso descrittore di processi, diverso spazio di indirizzamento, etc...) un conto sono i thread. C'è molta letteratura in giro che ti spiega per bene la differenza tuttavia il grosso vantaggio è che hai la possibilità di accedere alle variabili (condivise) del processo che li crea.
Nel tuo caso sei in multiprocesso. La fork() crea un processo.

Se vuoi utilizzare i thread, per il C, ci sono i POSIX thread (pthread).
Per creare un pthread si utilizza la pthread_create(..)
L'accesso alle variabili condivise avviene attraverso l'uso di semafori, (pthread_mutex_t). Tuttavia è un argomento troppo vasto per dare una spiegazione esaustiva ed alla fine scriverei un libro sulla programmazione concorrente :)

[Eddie1985]

Ti serve semplicemente di far partire la decompressione su un nuovo thread, che "possiede" un bool che è sempre false finchè non ha finito.

Poi nel thread principale metti


pthread_start( thread, decompress, file );

while( !decompressionHasFinished )
{
//anima la gui, fai quello che ti serve di fare
}

pthread_join( thread );


Quel while può anche essere il "main loop" del programma, quello che conta è che lanci la decompressione su un secondo thread e aspetti così che finisca (o con qualcosa di più complicato tipo una Condition o un pthread_mutex_trylock()).
Il multiprocesso non ti serve! :D
E' importante non usare wait() (nel caso del processo) o join() (nel caso del thread) subito, perchè altrimenti il primo thread si blocca in attesa del secondo... e in pratica hai un thread solo.


mmm qualcosa ho capito, anche se non tutto. il fatto è questo: io nel main ho creato vari thread che soddisferanno varie richieste giunte dal client (fra cui la compressione di file)....quando c'è una richiesta un thread chiama una funzione che supponiamo sia gestisci_richiesta() .... dentro questa funzione poi posso creare un altro thread come mi consigli tu?

[Eddie1985]

Un conto sono i processi (diverso descrittore di processi, diverso spazio di indirizzamento, etc...) un conto sono i thread. C'è molta letteratura in giro che ti spiega per bene la differenza tuttavia il grosso vantaggio è che hai la possibilità di accedere alle variabili (condivise) del processo che li crea.
Nel tuo caso sei in multiprocesso. La fork() crea un processo.

Se vuoi utilizzare i thread, per il C, ci sono i POSIX thread (pthread).
Per creare un pthread si utilizza la pthread_create(..)
L'accesso alle variabili condivise avviene attraverso l'uso di semafori, (pthread_mutex_t). Tuttavia è un argomento troppo vasto per dare una spiegazione esaustiva ed alla fine scriverei un libro sulla programmazione concorrente :)

si il programma che sto facendo usa i pthread....leggi il post sopra che ho appena scritto per capire la situazione :)

[Eddie1985]

scusami ma man serve solo a vedere il manuale o sbaglio? non e' una funzione...


serve per vedere il manuale e capire il funzionamento delle funzioni, ad esempio.
nel tuo caso mi sembra che devi capire il funzionamento della funzione execl (e probabilmente anche della tar) quindi usa pure la funzione man :D

[starfred]

Ok, se sei in multithread posta il codice, così ci si da un'occhiata.

[Eddie1985]

Ok, se sei in multithread posta il codice, così ci si da un'occhiata.

di quale parte del codice hai bisogno?

[starfred]

Se non è troppo lungo tutto. Altrimenti scrivici in pseudo-codice quello che fa tutto il programma.

[WarDuck]

il programma che devo scrivere (anzi che ho scritto) è multithread....puoi spiegarti meglio?


La fork crea un nuovo processo, che in particolare è la copia di quello padre, se aggiorni una variabile nel figlio il padre non la vede.

Chiamate come clone o pthread_create creano nuovi thread.

I thread fanno parte tutti dello stesso processo, ergo puoi accedere alle variabili del processo da qualsiasi thread. Di contro hai che se un thread crasha si porta appresso l'intero processo e tutti i thread ad esso associati.

Il tempo di creazione di un thread è tipicamente molto più basso rispetto a quello dei processi, per cui se devi istanziare una operazione asincrona di breve durata conviene usare i thread piuttosto che creare un nuovo processo.

Se devi gestire delle richieste che ti arrivano dalla rete, puoi usare diverse tecniche.

Ad esempio una tecnica può essere quella di fare pre-threading, ovvero creare più thread all'inizio in modo che le varie richieste vengano subito assegnate ad un dato thread. Una sorta di modello manager/worker.

[Eddie1985]

Se non è troppo lungo tutto. Altrimenti scrivici in pseudo-codice quello che fa tutto il programma.

il programma è lungo, ed è un'applicazione client-server.

comunque il problema di cui stiamo discutendo riguarda la parte server. Nel main creo un certo numero di thread con

pthread_t pool [NUM_THREADS];
for (i=0; i<NUM_THREADS; i++) {
pthread_create (&pool[i], NULL, gestisci_richiesta, 0);
}

ogni thread ha il compito di gestire una richiesta che proviene dal client. ho scelto di organizzare le richieste proveniente dal client. quindi la funzione gestisci_richiesta attende che vi sia almeno una richiesta nella lista, e in quel caso ne estrae una e la esegue.
supponiamo che la richiesta sia appunto quella di comprimere dei file, arriviamo appunto al problema che vi ho esposto :)
da notare che il programma mi funziona correttamente, se ad esempio dopo la execlp metto una sleep abbastanza alta e scelgo appositamente file che saranno compressi in breve tempo...

[starfred]

Ok, forse ho capito il problema.
Cerco di spiegare cosa avviene, così mi puoi correggere:

1) un client(C1) arriva e viene gestito da un thread singolo
2) il client chiama la funzione di compressione ed il server(S) inizia a comprimere il file
3) un altro client(C2) arriva, viene gestito da un altro thread e richiede il file compresso che però non è stato ancora compresso del tutto.

Esatto?

[Eddie1985]

La fork crea un nuovo processo, che in particolare è la copia di quello padre, se aggiorni una variabile nel figlio il padre non la vede.

Chiamate come clone o pthread_create creano nuovi thread.

I thread fanno parte tutti dello stesso processo, ergo puoi accedere alle variabili del processo da qualsiasi thread. Di contro hai che se un thread crasha si porta appresso l'intero processo e tutti i thread ad esso associati.

Il tempo di creazione di un thread è tipicamente molto più basso rispetto a quello dei processi, per cui se devi istanziare una operazione asincrona di breve durata conviene usare i thread piuttosto che creare un nuovo processo.

Se devi gestire delle richieste che ti arrivano dalla rete, puoi usare diverse tecniche.

Ad esempio una tecnica può essere quella di fare pre-threading, ovvero creare più thread all'inizio in modo che le varie richieste vengano subito assegnate ad un dato thread. Una sorta di modello manager/worker.

Ok, forse ho capito il problema.
Cerco di spiegare cosa avviene, così mi puoi correggere:

1) un client(C1) arriva e viene gestito da un thread singolo
2) il client chiama la funzione di compressione ed il server(S) inizia a comprimere il file
3) un altro client(C2) arriva, viene gestito da un altro thread e richiede il file compresso che però non è stato ancora compresso del tutto.



si è esattamente quello che ho fatto nel programma.... creare più thread all'inizio in modo che le varie richieste vengano subito assegnate ad un dato thread.
un client vuole comprimere dei file residenti in una cartella del server...quindi invia un certo comando al server che di conseguenza comprime i file e spedisce al client il file compresso....il problema che ho riguarda unicamente il server, che deve spedire al client il file compresso solo dopo un'opportuno intervallo di tempo...che però è variabile e non noto a priori, in quanto dipende da quanti file dovrà comprimere, dalla loro dimensione ecc

[starfred]

Il problema riguarda il multi-client, non il singolo client esatto?
Cioè un client(C1) arriva ed invia i comandi al server(S):

1) Comprimi ed enviami il file ("nomefile")
2) recv(buffer)

Il server(S) nel suo thread eseguirà:

1) Ricevo il nome del file
2) Comprimo il file
3) send(buffer)


In questo caso il codice funziona correttamente e non ha bisogno di correzione, in quando la recv() di C1 è bloccante ed il server invia il file solo dopo la compressione. Il tuo codice è così?

[Eddie1985]

Il problema riguarda il multi-client, non il singolo client esatto?
Cioè un client(C1) arriva ed invia i comandi al server(S):

1) Comprimi ed enviami il file ("nomefile")
2) recv(buffer)

Il server(S) nel suo thread eseguirà:

1) Ricevo il nome del file
2) Comprimo il file
3) send(buffer)


In questo caso il codice funziona correttamente e non ha bisogno di correzione, in quando la recv() di C1 è bloccante ed il server invia il file solo dopo la compressione. Il tuo codice è così?

si esatto il mio codice funziona così....però il problema è questo...dopo aver chiamato la execlp (e quindi iniziato la compressione), devo aprire questo archivio compresso con la fopen per poi inviarlo al client con la send....la fopen deve essere chiamata quindi solo dopo che l'archivio compresso sia stato completato del tutto, altrimenti mando un file parziale....mi sono spiegato?

[Tommo]

mmm qualcosa ho capito, anche se non tutto. il fatto è questo: io nel main ho creato vari thread che soddisferanno varie richieste giunte dal client (fra cui la compressione di file)....quando c'è una richiesta un thread chiama una funzione che supponiamo sia gestisci_richiesta() .... dentro questa funzione poi posso creare un altro thread come mi consigli tu?

Ovviamente puoi creare un thread in qualsiasi caso puoi chiamare pthread_create (non era pthread_start, giusto).

Di solito c'è un thread che rimane in listen in attesa di connessioni dal client; ogni volta che si crea una connessione, si usa pthread_create (o si pesca un thread libero dal pool) e si assegna il task al nuovo thread.
(puoi anche usare il polling con select() su un solo thread che gestisce tutte le connessioni E un thread per ogni pacchetto/task che arriva... ma è un bel casino).

Se l'architettura è questa credo sia inutile usare un secondo thread per fare la fopen e inviare, fai prima ad assegnare un thread per ogni client e fare fopen direttamente dopo la decompressione.
In quel modo non devi "attendere" niente perchè nel contesto del singolo thread, la decompressione è atomica.

[dierre]

uhm...ok non sono un programmatore C, quindi la domanda può risultare scema, ma non mi è chiara una cosa. Mi sono letto la manpage di execlp e la execlp ti ritorna un intero...quindi non basta che attendi che ti torna il valore e se tutto è andato bene invii indietro il file? Oppure la execlp è asincrona?

L'operazione della send non è all'interno dello stesso thread?

[Eddie1985]

Se l'architettura è questa credo sia inutile usare un secondo thread per fare la fopen e inviare, fai prima ad assegnare un thread per ogni client e fare fopen direttamente dopo la decompressione.
In quel modo non devi "attendere" niente perchè nel contesto del singolo thread, la decompressione è atomica.


l'archietettura è quella...per il resto non ho ben capito...io non devo decomprimere niente....devo solo inviare l'archivio compresso al client....e se non aspetto un tempo opportuno gli invio solo una parte dell'archivio compresso!


uhm...ok non sono un programmatore C, quindi la domanda può risultare scema, ma non mi è chiara una cosa. Mi sono letto la manpage di execlp e la execlp ti ritorna un intero...quindi non basta che attendi che ti torna il valore e se tutto è andato bene invii indietro il file? Oppure la execlp è asincrona?

in effetti potrebbe anche essere un'idea....qualcuno ne di più?

[Eddie1985]

ah scusa non avevo letto la parte finale...si la send fa parte dello stesso thread

[dierre]

beh se è dello stesso thread fare così non va bene?


int result = execlp (...);
if(result>-1) // mi pare che -1 sia l'unico intero che segnali l'errore
send();

[starfred]

Fai la exec in un thread?! Allora non funziona nulla. Quando esegui una exec() tutto il processo viene sostituito. Devi usare la system().

[Tommo]

l'archietettura è quella...per il resto non ho ben capito...io non devo decomprimere niente....devo solo inviare l'archivio compresso al client....e se non aspetto un tempo opportuno gli invio solo una parte dell'archivio compresso!


Non ho capito che senso ha... se nello stesso thread prima comprimi e poi invii, come fai a inviare solo una parte?

[Eddie1985]

Fai la exec in un thread?! Allora non funziona nulla. Quando esegui una exec() tutto il processo viene sostituito. Devi usare la system().

sei sicuro di quello che dici? io sapevo che la system corrispondeva ad una fork + una execl ..... qualcun altro può confermare quanto dice starfred?


Non ho capito che senso ha... se nello stesso thread prima comprimi e poi invii, come fai a inviare solo una parte?

quando chiamo la fork si crea un altro processo....quindi la compressione viene effettuata in un altro processo...boh almeno penso di aver capito così.....

[starfred]

Esatto, la system() esegue una fork ed una exec. Quando fai una chiamata viene creato un nuovo processo (fork()) e successivamente sostituito dalla chiama exec


padre
| system("comando")
----->fork() nuovo processo
exec() Esegui "comando"
Tutto il nuovo processo viene sostituito dal processo generato dal "comando"
ret
<----- |


Se tu fai

padre
| exec("comando")

Tutto il processo del padre viene sostituito dal processo generato dal "comando".

Quindi ricapitolando. Se sei in multithreading si utilizza la system(). Se sei in multiprocess si utilizza la exec().

[Eddie1985]

Esatto, la system() esegue una fork ed una exec. Quando fai una chiamata viene creato un nuovo processo (fork()) e successivamente sostituito dalla chiama exec


padre
| system("comando")
----->fork() nuovo processo
exec() Esegui "comando"
Tutto il nuovo processo viene sostituito dal processo generato dal "comando"
ret
<----- |


Se tu fai

padre
| exec("comando")

Tutto il processo del padre viene sostituito dal processo generato dal "comando".

Quindi ricapitolando. Se sei in multithreading si utilizza la system(). Se sei in multiprocess si utilizza la exec().

ma io prima della exec (comando) ho chiamato una fork!

[starfred]

Ma non eri in multithread? Hai fatto un misto?

Processo principale
|
Thread N-esimo
|
fork()
|
exec()

[Eddie1985]

Ma non eri in multithread? Hai fatto un misto?

Processo principale
|
Thread N-esimo
|
fork()
|
exec()


esatto! ho fatto un misto! con la system sarebbe stato lo stesso....

[starfred]

Ok, non è proprio l'equivalente della system() dato che quest'ultima è bloccante per chi la invoca. Per esser equivalente dovresti aspettare la terminazione del figlio. Quindi o sostituisci la parte di fork()+exec() con una semplice system() oppure metti una wait nel thread che crea il processo figlio.
Io ti consiglio di utilizzare la system().

[Eddie1985]

Ok, non è proprio l'equivalente della system() dato che quest'ultima è bloccante per chi la invoca. Per esser equivalente dovresti aspettare la terminazione del figlio. Quindi o sostituisci la parte di fork()+exec() con una semplice system() oppure metti una wait nel thread che crea il processo figlio.
Io ti consiglio di utilizzare la system().

ok chiaro. ci sono ancora due punti che nn mi sono chiari: la system (oppure la fork + exec) generano un altro processo oppure un altro thread?
nel caso scegliessi la strada fork + exec, dove devo mettere di preciso la wait? cioè faccio qualcosa del genere?

exec ( .... );
wait ();

[starfred]

La system (oppure la fork + exec) generano un altro processo.

Se proprio vuoi usare la fork+exec in modo che il padre attenda la fine del figlio puoi prendere spunto da questo codice

#include <stdio.h>
#include <unistd.h>

int main ()
{
int pid, status;

if(fork())
{
printf("Sono il padre ed attendo il figlio\n");
pid = wait(&status);
printf("Sono il padre, il figlio con PID %d e' terminato con status %d\n", pid, status);
}else{
printf("Sono il figlio ed eseguo il comando\n");
execl("/bin/ls", "ls","-l" , NULL);
printf("Impossibile!");
}

printf("Fine\n");
}

[Eddie1985]

esattamente la sintassi con la system come sarebbe?

int ret;
ret = system ("tar -zcf nome_archivio");

è così?

e poi un'ulteriore domanda....quando all'inizio creo il pool di thread....in base a cosa devo stabilire quanti thread creare?

[starfred]

esattamente la sintassi con la system come sarebbe?

int ret;
ret = system ("tar -zcf nome_archivio");

è così?

Sì, puoi fare un ulteriore controllo sul valore "ret" che ritorna la system.


e poi un'ulteriore domanda....quando all'inizio creo il pool di thread....in base a cosa devo stabilire quanti thread creare?



Eh dipende dalla tua applicazione, su quanto parallelismo vuoi e su quanti core girerà il programma... Sinceramente 4 thread mi sembra un buon approccio per la tua applicazione, ma potrebbero esser buoni anche 10 :D .
Per esempio, dato che sei su una configurazione client-server potresti fare una cosa del tipo:
- 20 connessioni massimo per il socket in coda.
- 4 thread che gestiscono in maniera concorrente la accept

Così se per esempio arrivano 30 connessioni:
6 vengono refused
20 rimangono in attesa
4 vengono servite

[Eddie1985]

Così se per esempio arrivano 25 connessioni:
5 vengono refused
11 rimangono in attesa
4 vengono servite


scusa 5+4+11 non fa 20? le connessioni che arrivano non sono 25?:confused:

[starfred]

Ho modificato il messaggio di prima.

[Eddie1985]

poi cmq come faccio per impostare il numero massimo di connessionni per socket?

[starfred]

Con la listen(), indichi la lunghezza della coda dei client in attesa su un determinato socket().

ps. Questo thread sta diventando una guida :D

[Eddie1985]

Con la listen(), indichi la lunghezza della coda dei client in attesa su un determinato socket().

ps. Questo thread sta diventando una guida :D


si infatti basta. grazie di tutto. :D

[marco.r]

Salve a tutti
dunque il problema che ho è questo: in un programma scritto in C che deve girare su un sistema Unix-like, devo comprimere alcuni file (non so quanti siano questi file e che dimensione abbiano), quindi devo fare altre operazioni che riguardano l'archivio compresso.
Ora il fatto è questo: mi servirebbe un ciclo di attesa che attenda la fine della compressione, in modo da non utilizzare l'archivio compresso che non è ancora stato totalmente compresso :D
Qualcuno ha qualche idea?

Per aspettare che il processo figlio finisca basta attendere una SIGCHLD, oppure usi la system che fa proprio questo.

[Eddie1985]

aspettate una cosa veloce per quanto riguarda la sintassi della system usando il comando tar.
come detto prima scriverei
system ("tar -czf nome_archivio");
ma nome_archivio è una variabile, io ovviamente voglio passare il contenuto della variabile...come si fa?

[marco.r]

Puoi provare con snprintf (http://linux.die.net/man/3/snprintf)

[Eddie1985]

Per aspettare che il processo figlio finisca basta attendere una SIGCHLD, oppure usi la system che fa proprio questo.

ma cosa devo scriverci come argomento della wait nel processo padre?

[Eddie1985]

no comunque non ci siamo ho ancora bisogno di aiuto :D
dunque ho scelto la strada fork + execlp .... ecco più o meno cosa ho fatto:


pid_t pid;
int status;

pid = fork ();

if (pid == 0) {
execlp ();
_exit (0);
}

else if (pid > 0)
wait (&status);

else {
perror ("ERROR: problema con la fork!\n");
exit (-1);
}

// codice



però c'è qualcosa che non va....qualcuno sa aiutarmi?

[starfred]

ciao, la _exit(0) dopo la execlp() non ha senso, per il resto mi sembra corretto.