[C] System Call UNIX (da guru)

[alesssia]

Se si sveglia dalla msgrcv perché ha ricevuto una signal allora lo faccio uscire da quel ciclo while, quindi, quando vi rientra, non serve la vecchia richiesta (già servita) ma si riaddormenta sulla msgrcv...

Forse non sono stata chiarissima, vero?!?

Sul man io non ho letto nessuna soluzione, per questo abbiamo messo questa "toppa"...

[mr.smile]

Io ho trovato questa soluzione... che proverò adesso... ma non so...

Il man parla dell' ERRNO

puoi controllare il valore dell'errno... e fargli eseguire il codice dopo msgrcv solo nel caso in cui sia uguale a EINTR...

ma non sono sicuro.... adesso proverò...!

Anche tu alle prese con l'esercizio del Gunetti..?

[mr.smile]

Ho provato... e....
FUNZIONA....!!!!!!!

i = msgrcv(msgid, &ricevitore, sizeof(BUFFER), RICEVI ,0);
		if (i == -1)
		{
			if (errno == EINTR)
			{
			printf("E' stata chiamata una signal e quindi io non mi sblocco", i);
			}
			else
				printf("gestione dei messaggi in  ricezione fallita", i);
		}
		else
		{
		...
		}

la msgrcf restituisce un intero... se tutto va bene... è un numero intero positivo... se qualcosa va storto... allora è -1 in particolare tramite l'errno puoi gestire la causa del problema... (io ho semplicemente fatto una stampa di controllo...)

QUINDI.... CASO RISOLTO....!!!!

[alesssia]

Sì, anch'io alle prese con il demone di gunetti...
Ottima soluzione, grazie.

Tra l'altro al lucido 11, in uno dei punti opzionali, si dice che il demone quando riceve una SIGUSR1 deve visualizzare tutti i messaggi e *chiedere* se si vuole cancellarli.
Ma il demone è lanciato in bg, quindi come fare?
Quando il demone riceve un SIGUSR1 lo si fa rorkare e si lascia al figlio il compito di visualizzare e gestire l'eventuale cancellazione dei messaggi, oppure si sveglia il demone, lo si porta in fg, lo si stoppa, lo si riporta in bg...?

Noi optavamo per la prima soluzione, ma non sappiamo quanto sia corretta...

PS. Per chi fosse interessato al caso è possibile vedere i lucidi all'indirizzo: http://www.di.unito.it/~gunetti/dida...ale03-04-3.pdf

[mr.smile]

Già... io volevo risolverla forkando... all'inizio del metodo chiamato dalla SIGUSR1 ma... non ci riesco proprio.. perchè sembra che anche il nuovo processo sia in backgroud.... tu hai risolto qualcosa?

[mr.smile]

Il punto è questo...

Quando un programma in background forka, il figlio rimane in background...

Qualcuno ha idea di un'istruzione c che porta in foreground un programma che è in background????

Altimenti noi abbiamo lavorato un po' sulle signal... ma non siamo riusciti a risolvere molto!

[mr.smile]

Hei... nessuno ha un'idea di come si possa fare questo? Non ci credo...!

Coraggio ragazzi...!

[alesssia]

Originariamente inviato da mr.smile
Qualcuno ha idea di un'istruzione c che porta in foreground un programma che è in background????

Poi fare delle execl di fg e bg, ma non so bene come...

Noi abbiamo smesso di lavorarci perché io sto preparando DB e il mio socio è al mare, appena ci rimettiamo sotto ti faccio sapere qualcosa!

[mr.smile]

Oggi andiamo dal prof.
ma ci sono un sacco di cosuccie che non funzionano...!

A te non capita di dovre chiamare più volte ricevi o rimuovi per ricevere i messaggi?
Io non riesco a capacitarmi del perchè...!

Per portare in bg il programma... abbiamo scoperto che se facciamo o una system("bg `n°pid`") o una execl(...) il sistema crea come una nuovo terminale all'interno del quale non sono visibili i processi...

Ma quello che ci preoccupa di più è questa stranezza del ricevi...

[alesssia]

Fammi sapere, mi raccomando... : )
Grazie mille!