Domanda

Sono stato coinvolto nella creazione di un'applicazione QGIS personalizzata in cui i dati in tempo reale devono essere mostrati sul visualizzatore dell'applicazione.

L'IPC utilizzato è unix code di messaggi.

I dati devono essere aggiornati a un intervallo specificato, ad esempio 3 secondi.

Ora il problema che sto affrontando è che l'elaborazione dei dati che devono essere mostrati richiede più di 3 secondi, quindi quello che ho fatto è che prima che l'app inizi a elaborare i dati per il prossimo aggiornamento, l'aggiornamento QTimer viene arrestato e dopo l'elaborazione dei dati riavvio nuovamente QTimer. L'app dovrebbe funzionare in modo tale che dopo un aggiornamento / aggiornamento (durante questo aggiornamento l'app non risponde) l'utente dovrebbe avere il tempo necessario per continuare a lavorare sul oltre a vedere i dati in fase di aggiornamento. Sono in grado di ottenere pause accettabili per far funzionare l'utente, in uno scenario.

Ma su diversi sistemi operativi (da RHEL 5.0 a RHEL 5.2) la situazione è diversa. Il timer si scatena e continua a funzionare senza dare alcuna pausa in b / n agli aggiornamenti successivi andando così in un ciclo infinito. Gestire definitivamente questi dati di aggiornamento richiede più di 3 secondi, ma proprio per questo motivo ho arrestato-riavviato il timer durante l'elaborazione .. e la stessa logica funziona in uno scenario mentre in altri no. L'altro fatto che ho osservato è che quando questo rapido sparo del timer si verifica il tempo impiegato dalla funzione di aggiornamento per uscire è molto piccolo di circa 300 ms, quindi l'inizio-fine del timer che ho posto all'inizio e alla fine di questa funzione avviene in quel piccolo tempo ... prima che il l'effettiva elaborazione dei dati termina, ci sono 3-4 inizi del timer in coda in attesa di essere eseguiti e quindi il problema del loop infinito peggiora da quel punto per ogni aggiornamento successivo.

La cosa importante da notare qui è che per lo stesso codice in un sistema operativo il tempo di aggiornamento è di circa 4000 ms (il tempo di elaborazione effettivo impiegato per la stessa quantità di dati) mentre per l'altro sistema operativo è di 300 ms.

Forse questo ha qualcosa a che fare con le nuove librerie sul sistema operativo aggiornato ... ma non so come eseguire il debug perché non sono in grado di ottenere alcun indizio sul motivo per cui sta accadendo in quanto tale ... forse qualcosa relativo ai pthreads è cambiato b / n i SO ??

Quindi, la mia domanda è che c'è un modo che assicuri che alcune elaborazioni nella mia app siano temporizzate (e che è indipendente dal sistema operativo) senza usare QTimer poiché penso che QTimer non sia una buona opzione per ottenere ciò che ho vogliono ??

Quale opzione può esserci ?? pthreads o Boost thread? quale sarebbe meglio se dovessi usare i thread come alternativa ?? Ma come posso assicurarmi almeno uno spazio di 3 secondi in b / n aggiornamenti successivi, non importa quanto tempo impiega l'elaborazione degli aggiornamenti?

Gentile aiuto.

Grazie.

È stato utile?

Soluzione

Se stavo cercando di ottenere una soluzione accettabile a lungo termine, avrei studiato l'aggiornamento del display in un thread separato. In quel thread, potresti dipingere il display su un'immagine, aggiornando tutte le volte che vuoi ... anche se potresti voler limitare il thread in modo da non impiegare tutto il tempo di elaborazione disponibile. Quindi nel thread dell'interfaccia utente, è possibile leggere l'immagine e disegnarla sullo schermo. Ciò potrebbe migliorare la tua reattività al panning, dal momento che potresti visualizzare diverse parti dell'immagine. Potresti aggiornare l'immagine ogni 3 secondi in base a un timer (ridisegna semplicemente dalla sorgente), oppure potresti fare in modo che l'altro thread emetta un segnale ogni volta che i nuovi dati sono completamente aggiornati.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top