Attualmente sto lavorando con un'applicazione Qt che tenta di utilizzare il multi-threading per realizzare due task
- Impedire che il loop eventi del thread principale venga bloccato
- Per aumentare l'efficienza di calcolo
Penseresti che sia una buona idea, ma risulta che potrebbe essere inefficiente. In Qt, il client non è autorizzato a creare un'istanza di una sottoclasse QWidget solo nel thread principale .
Il codice che ho visto finora sembra davvero disordinato. Il programma ha un "thread esecutivo", in altre parole un thread in background che gestisce la richiesta dell'utente (es. Clic del pulsante per un nuovo pannello gui), e ovviamente ci sono altri 3 thread (networking, elaborazione di script e ofcourse il thread principale)
L'installazione è abbastanza funky, l'evento action (es. Clic pulsante) viene segnalato al thread esecutivo, che quindi invia un funtore al thread principale per istanziare l'utente richiesto pannello gui.
Quanto sopra descritto non ha senso. Immagino che i progettisti originali fossero preoccupati del fatto che il thread fosse bloccato, ma ciò non avrebbe dovuto importare. Indipendentemente da quale thread è stato istanziato, finisce comunque nel thread principale, e comunque lo blocca.
Questa potrebbe non essere la scelta di design migliore, o è? Non sono sicuro, forse c'è qualcuno con più esperienza che può far luce su questo. Personalmente ritengo sia preferibile lasciare che un thread gestisca tutte le interazioni dell'utente, e qualsiasi elaborazione utente intensiva dovrebbe essere sottoposta a thread.
Le altre parti filettate hanno senso, avendo un thread separato per l'elaborazione degli script, in realtà la rete potrebbe aumentare l'efficienza, pur non bloccando il ciclo degli eventi principale in modo che la GUI possa rimanere interattiva.
Qualcuno potrebbe anche approfondire quando il multithreading è una buona scelta nella GUI, e in circostanze normali?
Grazie