Newsgroup: it.comp.os.linux.development
Titolo: Multithread e execlp()

Salve a tutti,
sto sviluppando un'applicazione multithread in cui faccio uso di una 
chiamata esterna per ordinare alfabeticamente le righe di un file di 
testo.
La mia applicazione è così strutturata:
-leggo da una coda di messaggi
-finchè trovo richieste di lettura creo un nuovo thread e vado a leggere 
nel file
-alla prima richiesta di inserimento aspetto che i thread di lettura 
siano tutti terminati e a quel punto inserisco la nuova riga nel file. 
A questo punto devo ordinare il file continuando a tenere bloccate 
ulteriori letture fino a quando l'ordinamento non sia completato.
Non sto usando semafori vista la natura sequenziale del mio approccio 
(quando inserisco uso il thread originario quindi le altre richieste 
vengono accodate senza essere servite). Per l'ordinamento ho fatto una 
semplice fork() seguita da un execlp(sort blablabla) ma così facendo non 
posso sapere quando il sort ha terminato e riprendere a servire le 
richieste in coda...o, peggio, ricomincio a servire le richieste mentre 
il file è ancora in fase di sorting.
Un modo per uscire da questa situazione?
-- 
N1 under...
zx-6r '04 Cocci & Dolori
CRe 250 '99 Almost Glue
XS 400 "90" Nescafè Racer

N1 ha scritto:



A parte il consiglio di usare una base dati piu' sofisticata di files flat
di linee ordinate che permetta anche inserimenti efficienti, o in seconda
ipotesi di eseguire il sort nel processo/thread principale senza l' ausilio
di un programma esterno... per rispondere direttamente al tuo quesito ti
dico di usare wait(2) o waitpid(2) per bloccare il processo che ha chiamato
fork() in attesa della terminazione del processo figlio che sta' eseguendo
il sort (fork(2) genera un processo, non un thread, la execlp(3) esegue
il nuovo codice nello stesso processo, quindi il PID non cambia).
Tra l' altro wait() dovresti chiamarla comunque, altrimenti ti rimangono
zombies.
Questo nell' ipotesi che il processo principale (thread principale) possa
essere bloccato per tutto il tempo necessario al sorting. Se non e' cosi',
per lasciargli le mani libere mi viene in mente una tecnica un po'
complessa
che obbliga a noiose attenzioni: usare in SIGCHLD, un signal che arriva dal
kernel al termine di un processo figlio.
E' semplicissimo definire un signal handler per SIGCHLD in cui esequire la
wait() o waitpid(), ma se in tale signal handler si deve anche settare una
var globale, come un flag tipo
int basedatibloccata = 0;
in modo che il processo principale per tutto il tempo in cui tale flag e'
a 1 prepara delle pre-elaborazione dei messaggi in coda senza accedere
alla base dati (sto generalizzando, non conosco il tuo codice) allora
l' handler si definisce "non rientrante". Settare un singolo int puo'
essere
una operazione atomica, ma se devi settare piu' variabili globali devi
proteggere tutte le parti di codice che vi accedono con sigprocmask(2)
con cui vieti che l' occorrenza del signal SIGCHLD attivi l' handler in
quel codice (l' ho detto che e' una cosa pallosa...)
Ciao
Roberto
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
la struttura dati non la decido io, è un progetto per l'uni per l'esame 
di sistemi operativi, non è su quello che mi devo concentrare.
per quanto riguarda wait e waitpid avevo già provato ma non aveva alcun 
esito...ora riprovo sostituendo al sort un semplice "digita un tasto per 
continuare" e vedo se prosegue anche senza aspettare l'immissione.
