Fonctionnement d'une classe Worker en thread

Version imprimable

24/09/2020, 11h58
Winounet

Fonctionnement d'une classe Worker en thread
Bonjour à tous,

J'ai une question d'ordre "fonctionnel" sur l'utilisation d'une classe Worker en thread. Je crois avoir compris dans les grandes lignes signaux/slots. Je ne suis pas un connaisseur de Qt en Python ou en C mais je vois l'idée et l'intérêt.

Je fais un GUI qui permettra de piloter beaucoup d'appareils et de gérer de multiples tâches dans le même temps. Idéalement j'imagine qu'en C++ je gagnerai en optimisation mais à l'instant t j'ai surtout des SDK Python...

Pour cela j'ai fait un main.py avec une interface et je cherche à avoir plusieurs processus que je peux lancer depuis le main (acquisition de données).
Code:

1 2 3 4 self.worker= Worker(self.data_1, self.data_2, self.data_3) self.thread_1 = QtCore.QThread() self.worker.moveToThread(self.thread_1) self.thread_1.start()
Puis dans le Worker je lance un while...
Mais lorsque j'ai un signal dans le main et que je veux lancer une fonction dans le Worker (type update d'un paramètre) et que j'utilise

Code:

self.worker.methode_1(self.update_data1)

est-ce que cela utilise le main ou le worker d'un point de vue thread ?
Je remarque que j'ai souvent des freezes et je soupçonne d'avoir mal optimisé les utilisations des threads qui permettrait de fluidifier l'interface.

Peut-être que ce n'est pas très clair
Merci

Bonjour,

Un des motifs courants de plantage avec QThread est quand on oublie qu'il ne doit pas comporter d'instruction graphique! Il n'est pas "thread-safe" (https://fr.wikipedia.org/wiki/Thread_safety).

A part ça, je préfère utiliser une classe héritant de QThread plutôt que le "moveToThread". Voilà un petit code pour illustrer mon propos:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
class Operationlongue(QtCore.QThread):
 
    # création des nouveaux signaux
    info = QtCore.pyqtSignal(int) # signal pour informer d'une progression
    fini = QtCore.pyqtSignal(bool, list) # signal pour la fin du thread
 
    #========================================================================
    def __init__(self, parent=None):
        super().__init__(parent)
 
        self.stop = False # drapeau pour exécuter une demande d'arrêt
 
    #========================================================================
    def run(self):
        """partie qui s'exécute en tâche de fond
        """
        for i in range(0, 101):
            if self.stop:
                break # arrêt anticipé demandé
            time.sleep(0.05)
            self.info.emit(i) # envoi du signal de progression d'exécution
        # fin du thread
        self.fini.emit(self.stop, [1,2,3]) # envoi du signal de fin d'exécution
 
    #========================================================================
    def arreter(self):
        """pour arrêter avant la fin normale d'exécution du thread
        """
        self.stop = True

Dans ce code, seule la méthode "run" est exécutée en tâche de fond. Ainsi, on peut appeler la méthode "arreter" qui change la variable stop pour arrêter la boucle for. Et quand la méthode run est terminée, le thread est terminé aussi.

30/09/2020, 14h42
Winounet

Bonjour et merci de ta réponse.

Je comprends un peu la notion de thread-safe et je n'y suis pas du tout avec mon programme. Car j'ai mon main, qui gère l'interface graphique à cela j'ajoute deux threads avec QThread (moveToThread, il y a une raison spécifique à ne pas utiliser cette fonction?) et un troisième qui est géré avec le module threading.

Séparément tout va bien mais ensemble ça ne fonctionne pas forcément très bien. Je vais relire en détail pour voir si je ne trouve pas des erreurs et des conflits. Par contre je vois que ce n'est pas Thread-safe d'utiliser des échanges entre les threads (mais bon j'ai parfois besoin de faire ça et je voulais m'éviter de passer par le main...)

Peut-être qu'il aurait été plus intelligent de faire le GUI lui aussi dans un thread et pas dans le main...
30/09/2020, 15h22
wiztricks

Salut,

Citation:

Envoyé par Winounet

Peut-être qu'il aurait été plus intelligent de faire le GUI lui aussi dans un thread et pas dans le main...

Vous avez des pages de documentations/tutos (dans la documentation Qt) qui racontent ce qu'on peut faire avec et quand faire quoi... notamment que les objets du GUI ne peuvent être que dans le thread principal.

- W
07/10/2020, 17h18
Winounet

Citation:

Envoyé par wiztricks

Salut,

Vous avez des pages de documentations/tutos (dans la documentation Qt) qui racontent ce qu'on peut faire avec et quand faire quoi... notamment que les objets du GUI ne peuvent être que dans le thread principal.

- W

Oui j'ai lu de la documentation et je continue d'en lire pour essayer de mieux comprendre le problème de mon soft, et j'ai vérifié déjà avec un seul thread, j'émets un signal et des 3 floats et j'ai l'impression que ça ne va pas aussi vite que je voudrais à l'affichage. Bref, c'est sans doute un combat avec moi-même qu'il reste :aie:
Mais ma question principale est répondue, je crois, un Worker permet de faire une opération spécifique mais ensuite quand j'émets des commandes depuis le thread principal pour update des datas dans le Worker je prends de la mémoire dans le thread principal?
Je marche un peu sur des oeufs quand même en disant ça. J'aimerais bien finalement avoir plusieurs threads principaux imbriqués les uns dans les autres avec même des bouts de GUI indépendants afin de ne pas ralentir un bout du soft quand j'update une commande sur un autre bout du soft.