Torna indietro   Hardware Upgrade Forum > Software > Programmazione

ASUS NUC 15 Pro e NUC 15 Pro+, mini PC che fondono completezza e duttilità
ASUS NUC 15 Pro e NUC 15 Pro+, mini PC che fondono completezza e duttilità
NUC 15 Pro e NUC 15 Pro+ sono i due nuovi mini-PC di casa ASUS pensati per uffici e piccole medie imprese. Compatti, potenti e pieni di porte per la massima flessibilità, le due proposte rispondono in pieno alle esigenze attuali e future grazie a una CPU con grafica integrata, accompagnata da una NPU per la gestione di alcuni compiti AI in locale.
Cybersecurity: email, utenti e agenti IA, la nuova visione di Proofpoint
Cybersecurity: email, utenti e agenti IA, la nuova visione di Proofpoint
Dal palco di Proofpoint Protect 2025 emerge la strategia per estendere la protezione dagli utenti agli agenti IA con il lancio di Satori Agents, nuove soluzioni di governance dei dati e partnership rafforzate che ridisegnano il panorama della cybersecurity
Hisense A85N: il ritorno all’OLED è convincente e alla portata di tutti
Hisense A85N: il ritorno all’OLED è convincente e alla portata di tutti
Dopo alcuni anni di assenza dai cataloghi dei suoi televisori, Hisense riporta sul mercato una proposta OLED che punta tutto sul rapporto qualità prezzo. Hisense 55A85N è un televisore completo e versatile che riesce a convincere anche senza raggiungere le vette di televisori di altra fascia (e altro prezzo)
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


ASUS NUC 15 Pro e NUC 15 Pro+, mini PC che fondono completezza e duttilità ASUS NUC 15 Pro e NUC 15 Pro+, mini PC che fondo...
Cybersecurity: email, utenti e agenti IA, la nuova visione di Proofpoint Cybersecurity: email, utenti e agenti IA, la nuo...
Hisense A85N: il ritorno all’OLED è convincente e alla portata di tutti Hisense A85N: il ritorno all’OLED è convi...
Acer TravelMate P6 14 AI: il Copilot+ PC sotto il chilo per il professionista in movimento Acer TravelMate P6 14 AI: il Copilot+ PC sotto i...
Recensione Borderlands 4, tra divertimento e problemi tecnici Recensione Borderlands 4, tra divertimento e pro...
Xbox Game Pass cambia: nuovi piani e pre...
Intel produrrà chip per AMD? L'in...
Ecco il nuovo Amazon Luna: videogiochi p...
ISRO: prosegue lo sviluppo della navicel...
CoD Black Ops 7 offrirà la beta p...
Il telescopio spaziale James Webb sta ai...
Crucial spinge sui moduli LPCAMM2: fino ...
Imgur blocca gli utenti del Regno Unito:...
ROG Xbox Ally già in consegna: qu...
Ubisoft annuncia Vantage Studios: Assass...
Il solare diventa la prima fonte di elet...
Google Home si rinnova completamente: ar...
Dense Geometry Format (DGF): novit&agrav...
Gemini for Home arriva a ottobre sui dis...
Amazon Smart Air Quality Monitor: a soli...
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: 23:13.


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