Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Qualcomm annuncia la nuova generazione di SoC Snapdragon 8 Elite Gen 6
Qualcomm annuncia la nuova generazione di SoC Snapdragon 8 Elite Gen 6
In occasione del proprio Snapdragon Summit Qualcomm annuncia i due nuovi chip per dispositivi mobile di fascia alta che entreranno nel mercato nel corso del 2027: tanta potenza a disposizione per elaborazioni di intelligenza artificiale sempre più complesse
realme 16 Pro Harry Potter Edition: il nuovo midrange ha uno stemma di Hogwarts che cambia colore al sole!
realme 16 Pro Harry Potter Edition: il nuovo midrange ha uno stemma di Hogwarts che cambia colore al sole!
Hogwarts arriva in fascia media grazie a realme, con una special edition che unisce la Quadra Light-Sensing Color-changing Tech, un baule in stile Hogwarts Express pieno di collezionabili e una scheda tecnica sostanzialmente identica al 16 Pro di partenza: ecco cosa cambia davvero, come si comporta nell'uso quotidiano e quanto vale in base al prezzo di 699,99 euro
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
REDMI Note 17 Pro porta in fascia media una batteria da 8.340 mAh con ricarica HyperCharge a 67W, un display AMOLED da 6,83 pollici capace di picchi di luminosità molto elevati e una struttura certificata TÜV SÜD contro cadute e infiltrazioni d'acqua, il tutto racchiuso in una scocca da 223 grammi. Lo abbiamo provato per diversi giorni tra fotocamera, prestazioni, autonomia e prezzo sul mercato italiano
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 22-07-2011, 14:03   #1
agosteeno
Member
 
Iscritto dal: Aug 2009
Messaggi: 119
[C] far eseguire un thread dopo la ricezione di alcuni signal

Salve a tutti, come da titolo vi chiedo un consiglio su un problema che ho un una mia applicazione. Sostanzialmente ho un thread che si occupa di effettuare una serie di operazioni generalmente tot secondi. Per fare questo fin'ora usavo una sleep tarata su questo valore all'interno di un ciclo while. Ora pero' devo sistemare l'applicazione in modo che possa gestire tutte le situazioni richieste da specifica. Oltre a dover essere eseguito ad ogni intervallo di tempo, deve esserlo anche quando il processo riceve un SIGINT o SIGTERM, in modo da completare le ultime operazioni e poi terminare oppure quando riceve un SIGUSR1. Questo serve perche' un altro thread che gestisce un particolare client gli vuole di chiedere di calcolare le richieste pendenti di quest'ultimo in modo che possa terminare e si aspetta di ricevere a sua volta un segnale di tipo SIGUSR2 che indica che ha terminato questa operazione. Io per fare questo ho fatto una cosa del genere:
Codice:
while(!terminaEsecuzione){
                sigemptyset(&set);
		sigaddset(&set, SIGALRM);
		sigaddset(&set,SIGINT);
		sigaddset(&set,SIGTERM);
		sigaddset(&set,SIGUSR1);
		/*
		 * blocco i segnali che dovranno essere attesi nella sigwaitinfo
		 */
		pthread_sigmask(SIG_SETMASK, &set, NULL);

                alarm(TOT_SECONDI);
		sigwaitinfo(&set, &info);
		switch (info.si_signo) {
		case SIGTERM:
		case SIGINT:
			terminaEsecuzione = 1;
			break;
		case SIGUSR1:
			daTerminare = info.si_pid;
			notificaTerminazione = TRUE;
		case SIGALRM:
                        /* qua nn faccio nulla, il programma deve continuare normalmente */
			printf("dentro Match: arrivato SIGALARM\n");
			break;
		default:
			break;
		}

... lavoro che deve eseguire il thread

                if(notificaTerminazione){
                         pthread_kill(daTerminare, SIGUSR2);
			 notificaTerminazione = FALSE;
                }
}
Il problema e' che nell'esecuzione della sigwaitinfo evidenziata in grassetto il processo viene ucciso e non capisco perche'...
Devo precisare che in questo momento non ci sono installati gestori per i segnali, ma prima ne avevo installato alcuni (che modificavano solamente variabili globali create per gestire queste situazioni ma il risultato e' rimasto lo stesso. Ho provato anche a cercare errori con valgrind ma nn mi ha dato nessun aiuto.
Qualcuno ha idea di quale potrebbe essere il problema o magari un consiglio per come organizzare la cosa in maniera diversa? Grazie a tutti quelli che parteciperanno
agosteeno è offline   Rispondi citando il messaggio o parte di esso
Old 22-07-2011, 14:44   #2
marco.r
Senior Member
 
Iscritto dal: Dec 2005
Città: Istanbul
Messaggi: 1817
Quote:
Originariamente inviato da agosteeno Guarda i messaggi
Salve a tutti, come da titolo vi chiedo un consiglio su un problema che ho un una mia applicazione. Sostanzialmente ho un thread che si occupa di effettuare una serie di operazioni generalmente tot secondi. Per fare questo fin'ora usavo una sleep tarata su questo valore all'interno di un ciclo while. Ora pero' devo sistemare l'applicazione in modo che possa gestire tutte le situazioni richieste da specifica. Oltre a dover essere eseguito ad ogni intervallo di tempo, deve esserlo anche quando il processo riceve un SIGINT o SIGTERM, in modo da completare le ultime operazioni e poi terminare oppure quando riceve un SIGUSR1. Questo serve perche' un altro thread che gestisce un particolare client gli vuole di chiedere di calcolare le richieste pendenti di quest'ultimo in modo che possa terminare e si aspetta di ricevere a sua volta un segnale di tipo SIGUSR2 che indica che ha terminato questa operazione. Io per fare questo ho fatto una cosa del genere:
Codice:
while(!terminaEsecuzione){
                sigemptyset(&set);
		sigaddset(&set, SIGALRM);
		sigaddset(&set,SIGINT);
		sigaddset(&set,SIGTERM);
		sigaddset(&set,SIGUSR1);
		/*
		 * blocco i segnali che dovranno essere attesi nella sigwaitinfo
		 */
		pthread_sigmask(SIG_SETMASK, &set, NULL);

                alarm(TOT_SECONDI);
		sigwaitinfo(&set, &info);
		switch (info.si_signo) {
		case SIGTERM:
		case SIGINT:
			terminaEsecuzione = 1;
			break;
		case SIGUSR1:
			daTerminare = info.si_pid;
			notificaTerminazione = TRUE;
		case SIGALRM:
                        /* qua nn faccio nulla, il programma deve continuare normalmente */
			printf("dentro Match: arrivato SIGALARM\n");
			break;
		default:
			break;
		}

... lavoro che deve eseguire il thread

                if(notificaTerminazione){
                         pthread_kill(daTerminare, SIGUSR2);
			 notificaTerminazione = FALSE;
                }
}
Il problema e' che nell'esecuzione della sigwaitinfo evidenziata in grassetto il processo viene ucciso e non capisco perche'...
Devo precisare che in questo momento non ci sono installati gestori per i segnali, ma prima ne avevo installato alcuni (che modificavano solamente variabili globali create per gestire queste situazioni ma il risultato e' rimasto lo stesso. Ho provato anche a cercare errori con valgrind ma nn mi ha dato nessun aiuto.
Qualcuno ha idea di quale potrebbe essere il problema o magari un consiglio per come organizzare la cosa in maniera diversa? Grazie a tutti quelli che parteciperanno
come viene ucciso ? segmentation fault ?
In ogni caso non controlli i risultati di tutte le operazioni precedenti... prova a dare una occhiata se una di quelle ti ritorna errore...
__________________
One of the conclusions that we reached was that the "object" need not be a primitive notion in a programming language; one can build objects and their behaviour from little more than assignable value cells and good old lambda expressions. —Guy Steele
marco.r è offline   Rispondi citando il messaggio o parte di esso
Old 22-07-2011, 14:54   #3
agosteeno
Member
 
Iscritto dal: Aug 2009
Messaggi: 119
Credo di aver capito il problema. Mi sono reso conto che il processo veniva ucciso perche' si aveva la trattazione di default per SIGALRM. Tramite valgrind mi sono reso conto che avviene nella accept che serve per accettare nuovi client. Il fatto e' che se installo un gestore poi nn riesco a usare la alarm come vorrei, nel senso che la sigwaitinfo nn riceve nessun segnale! Per quanto riguarda il controllo degli errori ora mi adopero a sistemare.
agosteeno è offline   Rispondi citando il messaggio o parte di esso
Old 22-07-2011, 14:58   #4
agosteeno
Member
 
Iscritto dal: Aug 2009
Messaggi: 119
Questo di preciso quello che mi scrive valgrind:
Codice:
==7122== 
==7122== Process terminating with default action of signal 14 (SIGALRM)
==7122==    at 0x40477F8: accept (socket.S:100)
==7122==    by 0x804AAFD: main (mgserver.c:1095)
==7122==
agosteeno è offline   Rispondi citando il messaggio o parte di esso
Old 22-07-2011, 15:06   #5
agosteeno
Member
 
Iscritto dal: Aug 2009
Messaggi: 119
siccome mi sono reso conto che il processo muore perche' e' il main a riceve il segnale invece che il thread che vorrei io, ho provato a chimare, invece che la alarm, la pthread_kill, specificando il thread stesso come destinatario, in questo modo:
Codice:
pthread_kill(pthread_self(), alarm(TOT_SECONDI));
ma la cosa nn e' cambiata e mi ha dato lo stesso errore. Come e' possibile secondo voi? E' sbagliato il modo di mandare il segnale?
agosteeno è offline   Rispondi citando il messaggio o parte di esso
Old 22-07-2011, 15:27   #6
agosteeno
Member
 
Iscritto dal: Aug 2009
Messaggi: 119
forse ho capito come risolvere: prima di far eseguire il main principale, eseguo una funzione che mi installa tutti i gestori. Semplicemente qua faccio in modo che non vengano ascoltati i segnali che mi interessano, mentre invece, quando eseguo il thread interessato rifaccio una nuova maschera (come il codice precedente) e posso usare il segnale che nn interferira' con gli altri... Speriamo vada bene
agosteeno è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Qualcomm annuncia la nuova generazione di SoC Snapdragon 8 Elite Gen 6 Qualcomm annuncia la nuova generazione di SoC Sn...
realme 16 Pro Harry Potter Edition: il nuovo midrange ha uno stemma di Hogwarts che cambia colore al sole! realme 16 Pro Harry Potter Edition: il nuovo mid...
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce Recensione REDMI Note 17 Pro: il midrange con ba...
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema Insta360 Luna Ultra: la potenza del sensore da 1...
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa Marvel's Wolverine, la recensione: Logan torna p...
ESA e Mistral hanno stretto un accordo p...
AstroForge presenta Autonomy-1: un satel...
Neutralizzata da Microsoft EvilTokens, l...
Porsche mette alla prova i Tesla Superch...
Roborock Saros 20 Flow Complete arriva i...
Basta un comando digitato nel terminale ...
La corsa alla superintelligenza è...
Le memorie cinesi sfidano sé stes...
Dash cam 4K con doppia telecamera, GPS, ...
Qwen 4: Alibaba conferma l'addestramento...
Super El Niño, allarme globale: 451.000 ...
Toyota, 400.000 robot in fabbrica senza ...
Hanno bucato l'FBI e ora dettano le cond...
Standard sì, licenze no: la linea di Ope...
Guida all'acquisto: quale smartphone HON...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 19:45.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v