Attention : article assez technique !
Je dois dire que le bug dont je vais traiter dans cet article, et que je traine depuis plusieurs mois déjà, me laissait particulièrement perplexe.

Conditions pour le reproduire :

- ouvrir la fenêtre de Perfs/Stats
- demander à fermer le rapidement le programme, avant que la fenêtre ait terminé de tout initialiser

Résultat : la fenêtre de Perfs (et donc le programme) met plus de 5 seconde à se fermer, mais sans provoquer de crash. Juste un temps anormalement de fermeture long.

J’en ai passé du temps, à mettre des infos de logs un peu partout pour comprendre d’où venait le problème.

Pour y voir plus clair, il faut bien comprendre que cette fenêtre de Perfs utilise un composant qui s’occupe de récupérer les infos, et tracer les graphiques.
Il y a une instance du composant par graphique, et chaque instance lance son travail dans un thread différent.
En résumé, chaque graphique (instantané ou d’historique) tourne dans son propre thread.

J’ai fini par identifier que tout le problème était dû à l’arrêt d’un thread, qui prenait un temps monstreux, sans raison apparente.

Avec Visual Studio, j’ai donc lancé la fenêtre d’examen des threads, et je me suis aperçu qu’un le thread en question était en priorié « au dessus de la normale ».

En fait, pour que les graphs soient « synchro », j’ai fait le choix de mettre les graphiques de type « historique » en priorité élevée.

Et c’est là tout le problème. Pour une raison obscure, une demande d’arrêt du thread trop rapidement faisait ramer le bazar.

Mais ce qui m’a dérouté, c’est que seul un thread ait cette priorité, alors que j’avais plusieurs graphiques de type historique.

En fait, lors de l’init de base du composant, celui-ci est automatiquement en mode historique.
Mais je ne modifiais la priorité que lors d’un appel explicite à un changement de type de graphique.

Au final, la solution a été simple.
J’ai forcé explicitement le type des graphiques lors de l’instantiation pour qu’ils passent en priorité haute, et dans la procédure qui traite l’arrêt des threads, je force d’abord le thread courant en priorité basse.
Et ô miracle, plus de problème !

Et en plus, ça m’a permis de voir que, contrairement à ce que je pensais, mes graphiques ne tournaient pas tous à la priorité voulue !
Résultat : deux problèmes corrigés à la fois.

Bon, mis à part ça, j’ai bien avancé sur le fichier d’aide, ainsi que sur son intégration dans le programme.
La sortie approche donc à grands pas …