Version imprimable
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 ?
Hello,
Ensemble intéressant, voici quelques remarques qui me semblent empêcher l'optimisation (ce qui semble être recherché sur ce sujet).
- 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 ?
- 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 ?
- 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.
Hey, merci d'être venu. Sais pas comment tu as su que ce code venait d'arriver mais c'est sympa :coucou:Citation:
Envoyé par fred1599
Euh... :koi:... 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.Citation:
Envoyé par fred1599
=> todo list !!! :ave:
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 listCitation:
Envoyé par fred1599
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).Citation:
Envoyé par fred1599
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 :aie: 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.Citation:
Envoyé par fred1599
ihm est un choix discutable, mais n'indique pas une mauvaise qualité d'un code sur son ensemble...Citation:
Envoyé par Sve@r
Ce n'est effectivement pas un changement de "2 minutes" car il faut modifier la communication entre le thread et le widget.Citation:
Envoyé par Sve@r
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é :applo:Citation:
Envoyé par fred1599
La version a été uploadée :lahola:
À mon avis, l'idéal serait de compter les lignes en itérant sur le fichier sans tout chargerCitation:
Envoyé par Sve@r
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
Tu as mille fois raison (j'ai pas réfléchi sur ce coup là)... => faitCitation:
Envoyé par fred1599
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".Citation:
Envoyé par papajoker
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"...
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)...Citation:
Envoyé par papajoker
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). :?Citation:
Envoyé par papajoker
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...Citation:
Envoyé par papajoker
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à.Citation:
Envoyé par papajoker
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).
Oui ça je trouve pas mal => fait (uploadé)Citation:
Envoyé par papajoker
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 ?
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.Citation:
Envoyé par fred1599
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é)
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.Citation:
Envoyé par sve@r
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).Citation:
Envoyé par Sve@r
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.
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().Citation:
Envoyé par fred1599
Compris :ave: (uploadé).Citation:
Envoyé par fred1599
Compris :ccool: (uploadé)Citation:
Envoyé par fred1599
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)...Citation:
Envoyé par fred1599
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.Citation:
Envoyé par Sve@r
Par contre je rendrai cette méthode stop plus robuste,
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.Code:
2
3
Ok, super :ccool:Citation:
Envoyé par fred1599
De nouveau => uploadé :chin: