Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio
Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio
POCO F9 Pro arriva sul mercato con l'obiettivo di portare prestazioni da smartphone top di gamma in una fascia di prezzo "più aggressiva", senza rinunciare a un comparto fotografico finalmente all'altezza. Dopo averlo testato sul campo, emerge uno smartphone molto più completo rispetto alla generazione precedente, ma anche con alcuni piccoli compromessi che diventano difficili da ignorare quando il prezzo di listino sfiora i 1.000 euro.
Tra audio e AI: la ricetta di Qualcomm per l'agentic AI
Tra audio e AI: la ricetta di Qualcomm per l'agentic AI
Snapdragon Soung Gen 2 è la piattaforma Qualcomm per i dispositivi audio sempre più integrati nel mondo dell'intelligenza artificiale: al prorpio interno tanta potenza elaborativa per gestire al meglio le necessità d'uso dell'agentic AI
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
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


Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio Recensione POCO F9 pro: potenza da vero top di g...
Tra audio e AI: la ricetta di Qualcomm per l'agentic AI Tra audio e AI: la ricetta di Qualcomm per l'age...
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...
Opera: la VPN gratuita si accende in aut...
Giochi capaci di costruirsi in tempo rea...
Giochi DX11 su Intel Arc e Proton: le ot...
Bentley Torcal ufficiale: 876cv e ricari...
Counter-Strike 2: con poche modifiche, V...
Silent Hill potrebbe tornare al cinema c...
L'integrazione di ChatGPT su Siri è stat...
ASML: 'Non vendiamo assolutamente nulla ...
Anthropic limita Claude Opus 5.5 nello s...
Microsoft 365, l'Antitrust respinge le p...
SAP NOW AI Tour Milan: una giornata con ...
Quake Champions dice addio al free-to-pl...
Anker AeroClip 2, li indossi e dopo un p...
Notebook ASUS da gaming per il Back to S...
Auto elettriche UE al 21,7%: sorpasso si...
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: 01:47.


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