Discussion :

[Sve@r]

Bonjour,

Je vous propose un nouvel élément à utiliser : traiter des fichiers en thread

Après Le QThread de Tyrtamos, cet exemple montre faire traiter des fichiers divers dans des thread.

Le but est de pouvoir sélectionner plusieurs fichiers, chaque fichier sera alors itéré dans un QThread ligne par ligne et chaque ligne traitée par un traitement défini par callback.

Cet exemple est disponible dans les versions PyQt5, PyQt6 et PySide6.

Qu'en pensez-vous ?

[fred1599]

Hello,

Ensemble intéressant, voici quelques remarques qui me semblent empêcher l'optimisation (ce qui semble être recherché sur ce sujet).

1. Ligne 486 "lig" : len(fic.read_text().split("\n")) - 1. Pour de très gros fichiers, cela peut consommer beaucoup de mémoire et prendre du temps, bloquant potentiellement l'interface utilisateur pendant cette initialisation. Possible de faire ce comptage dans le thread de travail ?
2. Ligne 530 self.__work.terminate(). Il arrête le thread de manière abrupte, sans lui donner la chance de libérer proprement ses ressources. La méthode stop semble être plus adapté, qu'en penses-tu ?
3. Ligne 522 QApplication.processEvents(). Je laisserai la boucle d'événements principale de Qt gérer cela.

En résumé, le code est de bonne qualité et bien commenté... Il y a en grande partie le principe SOLID de respecter sauf le O qui est discutable, mais pas gênant car suit une adaptation liée au besoin.

[Sve@r]

Hello,

Hey, merci d'être venu. Sais pas comment tu as su que ce code venait d'arriver mais c'est sympa

Ligne 486 "lig" : len(fic.read_text().split("\n")) - 1. Pour de très gros fichiers, cela peut consommer beaucoup de mémoire et prendre du temps, bloquant potentiellement l'interface utilisateur pendant cette initialisation. Possible de faire ce comptage dans le thread de travail ?

Euh... ... je n'y avais pas pensé. Le souci c'est que la fenêtre qui gère l'affichage de la barre de progression affiche aussi le fichier en cours avec son nombre de lignes (et je ne veux pas céder à la facilité en supprimant cette "cosmétique"). Donc il faut que le thread informe la fenêtre quand le comptage est fait. Faisable mais pas en 2mn.
=> todo list !!!

Ligne 530 self.__work.terminate(). Il arrête le thread de manière abrupte, sans lui donner la chance de libérer proprement ses ressources. La méthode stop semble être plus adapté, qu'en penses-tu ?

Je débute avec les thread et je ne connaissais pas la différence. Je ne peux donc qu'être d'accord avec toi qui semble connaitre mieux que moi => todo list

Ligne 522 QApplication.processEvents(). Je laisserai la boucle d'événements principale de Qt gérer cela.

Ca je l'ai vu dans un exemple. J'ai copié. Mais je ne sais pas si c'est réellement utile (d'où mon commentaire).

En résumé, le code est de bonne qualité et bien commenté...

Oups, suis en train de discuter en privé avec papajoker qui n'a pas le même avis à propos de mon dictionnaire "ihm" permettant de transmettre les infos entre les objets Mais c'est pas grave, tant que la discussion se fait dans la bonne humeur. Qt c'est vaste et pas facile et on peut se fourvoyer facilement.

[fred1599]

suis en train de discuter en privé avec papajoker qui n'a pas le même avis à propos de mon dictionnaire "ihm" permettant de transmettre les infos entre les objets

ihm est un choix discutable, mais n'indique pas une mauvaise qualité d'un code sur son ensemble...

Faisable mais pas en 2mn

Ce n'est effectivement pas un changement de "2 minutes" car il faut modifier la communication entre le thread et le widget.

[Sve@r]

Ce n'est effectivement pas un changement de "2 minutes" car il faut modifier la communication entre le thread et le widget.

Ok c'est fait. Et testé sur un fichier de 41M de lignes. Effectivement le comptage est long. Il y a une énorme tempo entre le moment où le thread est créé et le moment où le fichier commence à être lu mais ça ne bloque pas la fenêtre de gestion des fichiers et on peut donc rajouter d'autres fichiers pendant que le premier est toujours en train d'être compté
La version a été uploadée

[fred1599]

Effectivement le comptage est long. Il y a une énorme tempo entre le moment où le thread est créé et le moment où le fichier commence à être lu

À mon avis, l'idéal serait de compter les lignes en itérant sur le fichier sans tout charger

[papajoker]

Quelques (autres) remarques
- dommage que le "métier" soit trop imbriqué dans __QtWork, pour moi aucune bonne raison que __QtWork connaisse la nature du travail : ce n'est qu'un widget généraliste.
par exemple :
self.__fic["lig"] pourrait par exemple être envoyé dans le signal sigInfo / "__slotProgress", sigInfo peut envoyer le nombre de lignes du fichier. Voir même sigInfo retourne directement un pourcentage.
self.__fic["nom"] même chose avec __slotStop

- intéressant a faire :
* pouvoir sélectionner plusieurs fichiers .... (Imaginons que j'ai 12 download en parallèle à faire)
* faire une pause lorsque je clic sur stop (sinon le temps de cliquer sur confirmation et c'est déjà fini)
* pourquoi pas ? en option, ajouter le contenu de la ligne au signal "sigInfo" si on ne désire pas utiliser dans certains cas la fonction callback

[Sve@r]

À mon avis, l'idéal serait de compter les lignes en itérant sur le fichier sans tout charger

Tu as mille fois raison (j'ai pas réfléchi sur ce coup là)... => fait

- dommage que le "métier" soit trop imbriqué dans __QtWork, pour moi aucune bonne raison que __QtWork connaisse la nature du travail : ce n'est qu'un widget généraliste.

Ca m'a aussi un peu trituré. Malheureusement comment faire autrement ? Déjà dans la première version c'était pire, il n'y avait même pas de callback. QtWork affichait juste la ligne (et charge à l'utilisateur de changer cela s'il le désire). C'était juste un "proof of concept".
Donc là j'ai mis ça un peu à l'arrache. Effectivement j'aurais dû mettre le traitement en paramètre du QListWork (c'est lui l'objet Qt utilisable). C'est un peu mon souci (et j'en ai conscience), j'essaye de créer des objets indépendants (utilisable par quiconque) mais ensuite quand je les programme j'oublie ce "voeu pieu"...

self.__fic["lig"] pourrait par exemple être envoyé dans le signal sigInfo

Au début (pour faire la modif suggérée par fred) j'y avais pensé (ça m'embêtait de créer un signal juste pour ça). Mais cela signifiait alors que le(s) slot(s) associé(s) au signal allai(en)t devoir analyser l'information reçue et ça ça m'embêtait encore plus (en plus je pensais que tu serais le premier à me reprocher un signal top "généraliste" à devoir ensuite analyser)...

self.__fic["nom"] même chose avec __slotStop

Lui en plus il peut gicler (je l'ai mis juste pour ne pas avoir à utiliser self.__fic["path"].name à chaque fois que je voulais afficher le nom).

* pouvoir sélectionner plusieurs fichiers .... (Imaginons que j'ai 12 download en parallèle à faire)

Oui pas mal... => todo (mais pas de suite, surtout que le truc a une limite et donc il faut aussi gérer si l'utilisateur demande directement 12 fichiers alors que la limite est à 3). A réfléchir donc...

* faire une pause lorsque je clic sur stop (sinon le temps de cliquer sur confirmation et c'est déjà fini)

Non là je ne pense pas. Est-ce gênant si le fichier continue à être traité pendant que l'utilisateur réfléchit s'il veut vraiment quitter ? Il réfléchit il réfléchit et pouf, finalement c'est terminé et voilà.
En plus j'en ai bavé pour mettre la question en laissant le fichier se dérouler. Parce que dans la version de départ il n'y avait même pas de question. L'utilisateur cliquait sur "stop" et le truc s'arrêtait direct. Puis je me suis dit que ce serait sympa de rajouter une question subsidiaire, et ça me semblait pas compliqué (rajouter la question dans le slotStop). Mais là j'ai eu un gros souci : quand la question était posée mais que le fichier arrivait au bout sans que le user ait répondu, il était supprimé de la mémoire et j'obtenais une erreur "double free or corruption (out)" (probablement à cause de la QMessageBox toujours ouverte). D'où le rajout d'un flag "user" (que j'ai intégré dans les éléments du fichier pour simplifier) permettant de ne pas envoyer de signal "travail terminé" si la question était toujours en cours (mais en revanche qu'il faut alors envoyer quand le fenêtre se referme et si le travail est terminé). Donc trop bavé pour supprimer cette sympathique possibilité (laisser le thread travailler pendant la question).

* pourquoi pas ? en option, ajouter le contenu de la ligne au signal "sigInfo" si on ne désire pas utiliser dans certains cas la fonction callback

Oui ça je trouve pas mal => fait (uploadé)

[fred1599]

C'est beaucoup mieux !

Je ne vois pas ce qu'apporte self.__work.terminate() et QApplication.processEvents(), si on les supprime est-ce qu'on maintient une stabilité de l'application ?

[Sve@r]

Je ne vois pas ce qu'apporte self.__work.terminate() et QApplication.processEvents(), si on les supprime est-ce qu'on maintient une stabilité de l'application ?

Alors... pour le processEvents() j'avais trouvé ça chez tyrtamos qui m'a beaucoup appris. C'était ici: https://python.jpvweb.com/python/mes...console_python. Il indique que ça force le rafraichissement en temps réel. Cela ne devrait pas gêner de ne pas le mettre. En revanche, là où je l'ai mis, c'est idiot. C'est dans le sloProgress qu'il faut (enfin en admettant qu'il le faille) le mettre.

En ce qui concerne terminate(), c'est vraiment pas malin (je viens de voir la doc qui dit qu'effectivement c'est dangereux) mais là où je l'ai mis, c'est moindre mal. Parce que là où je l'ai mis, il n'est appelé qu'au moment où la fenêtre se ferme (méthode close()). Le slot d'arrêt (slotStop) ne fait qu'appeler la méthode stop() du thread qui place le flag en position arrêt (le thread quitte alors la boucle de façon "naturelle" ce qui est la méthode généralement recommandée. Donc déjà le slotStop n'arrête pas le thread de façon sale.

D'ailleurs, en mettant terminate() (ou même quit()) dans le slotStop, ça change pas mal de choses. Déjà quit() ne marche pas (je vois derrière le fichier continuer à s'afficher). Et terminate() arrête le thread mais comme le thread n'a pas le temps d'envoyer le signal, le truc reste dans la liste des fichiers et ne peut pas être enlevé.

Ceci dit, même s'il ne gêne pas là où il est, je dois quand-même le supprimer. Mais là j'ai 2 choix

• le remplacer par quit()
• laisser juste stop() qui de toute façon fait déjà l'arrêt de façon propre

Je crois que je vais le remplacer par quit() mais mettre l'instruction en commentaire... => c'est fait (uploadé)

[fred1599]

Alors... pour le processEvents() j'avais trouvé ça chez tyrtamos qui m'a beaucoup appris. C'était ici: https://python.jpvweb.com/python/mes...console_python. Il indique que ça force le rafraichissement en temps réel. Cela ne devrait pas gêner de ne pas le mettre.

La plupart du temps, ce n'est pas nécessaire. La boucle d'événements de Qt est très efficace. Il est préférable de le supprimer et de ne le réintroduire que si tu observes concrètement un problème de rafraîchissement visuel que seul processEvents() résout. Même dans ce cas, il faut l'utiliser avec parcimonie.

Je crois que je vais le remplacer par quit() mais mettre l'instruction en commentaire...

Ton thread __cWork exécute une tâche simple dans run() et n'a pas sa propre boucle d'événements Qt, donc quit() n'a pas l'effet escompté ici (il ne va pas interrompre ta boucle for).

Question : Pourquoi avoir commenté wait() ?

Toujours utiliser wait() après avoir demandé l'arrêt coopératif d'un thread, pour s'assurer qu'il a bien terminé avant de continuer et de détruire les objets dont il pourrait dépendre.

[Sve@r]

Question : Pourquoi avoir commenté wait() ?

Je pensais que puisque je passais par la méthode propre (positionnement du flag ce qui amène le thread a s'arrêter de par la fin de la boucle), cela ne devenait plus nécessaire. Dans ma tête j'associais wait() avec terminate (ou quit) donc puisque pas de quit(), alors pas besoin de wait().

Toujours utiliser wait() après avoir demandé l'arrêt coopératif d'un thread, pour s'assurer qu'il a bien terminé avant de continuer et de détruire les objets dont il pourrait dépendre.

Compris (uploadé).

La boucle d'événements de Qt est très efficace. Il est préférable de le supprimer et de ne le réintroduire que si tu observes concrètement un problème de rafraîchissement visuel que seul processEvents() résout. Même dans ce cas, il faut l'utiliser avec parcimonie.

Compris (uploadé)

[fred1599]

Top ! Pour moi la revue est terminée

[Sve@r]

Top ! Pour moi la revue est terminée

Oui vu l'heure (en plus à 10h30 j'avais envie d'aller au lit)... mais je viens d'y penser: puisque wait() est obligatoire, peut-on alors intégrer directement un self.wait() dans la méthode stop()... ? En temps ordinaire je dirais oui mais comme le thread c'est pas tout à fait un truc ordinaire (parce que cela revient à lui demander de s'attendre lui-même)...

[fred1599]

mais je viens d'y penser: puisque wait() est obligatoire, peut-on alors intégrer directement un self.wait() dans la méthode stop()... ?

Oui tu peux, et cela fonctionnera comme attendu parce que la méthode stop() de ton objet thread (self.__work.stop()) est appelée par un autre thread (le thread principal de l'IHM). C'est ce thread appelant qui exécutera le self.__work.wait() et attendra.

Par contre je rendrai cette méthode stop plus robuste,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if QThread.currentThread() != self:
    self.wait()

car tu as raison sur ta remarque, un thread ne peut pas attendre que sa propre exécution principale (run()) se termine de cette manière, car il se bloquerait lui-même indéfiniment.

[Sve@r]

Par contre je rendrai cette méthode stop plus robuste,

Ok, super
De nouveau => uploadé