Ho un'applicazione GUI che utilizza pthread per eseguire pesanti elaborazioni in background.Thread di sfondo durante l'utilizzo di pthreads (nice, priority)
Mentre l'elaborazione in background è in esecuzione, la GUI è molto poco reattiva e penso che questo sia dovuto alla mancanza di tempo della CPU da parte dei thread in background.
Su Windows è possibile :: SetThreadPriority (hThread, THREAD_PRIORITY_BELOW_NORMAL) sui thread in background e tutto va bene.
Tuttavia su Linux sto usando pthreads e non riesco a trovare una buona alternativa.
Ho già preso in considerazione;
- :: sched_setscheduler (SCHED_FIFO) o :: sched_setscheduler (SCHED_RR) - questo non è praticabile in quanto richiede root (non bello per il mio GUI app) - anche questo renderà il filo GUI avere modo troppo CPU ; Voglio solo che la GUI abbia la priorità sui thread in background.
- :: pthread_setschedparam ma quando si utilizza qualcosa di diverso da SCHED_FIFO o SCHED_RR che non è supportato (:: sched_get_priority_min (SCHED_OTHER) e :: sched_get_priority_max (SCHED_OTHER) entrambi tornare 0)
- avere più processi e utilizzare :: bello. C'è troppa connessione tra la GUI e i thread in background per renderlo fattibile (e portare così tanto codice a questo progetto è una grande quantità di lavoro)
- Usa :: setpriority per rielaborare i thread in background. Questo funziona - ma è direttamente contro ciò che dice la documentazione: PThreads documentation (così potrebbe potenzialmente essere "fisso" a livello di sistema in un secondo momento)
Sono convinto che questo è un modello abbastanza comune per le applicazioni GUI quindi cosa ho perso?
Marcus.
EDIT: Aggiunto :: setpriority alla lista di opzioni (grazie ZalewaPL)
"* ... troppo accoppiamento tra la GUI e le thread in background ... *" Mi piacerebbe iniziare a più di pensare il design, SRY. – alk
Non sono sicuro che sia utile - non c'è motivo di non avere molto traffico tra l'interfaccia utente e un thread in background, ed è abbastanza ragionevole non voler effettuare il porting su comunicazioni cross-process. –