Il y aura sans doute moins de nouveautés que dans la v3.3, mais ce changement de numéro de version est dû à toutes les modifications internes que je prévois de faire.

Comme pour la v3.3, il y aura un certain nombre de version beta différentes, afin de bien scinder le travail d’ajout de nouvelles fonctions.
Mais pour le moment, je n’ai pas trop le temps de coder. En effet, nous sommes en juin, et le planning familial est bien chargé, entre les kermesses, les réunions à droites et à gauche …

Quoi qu’il en soit, ce que j’ai déjà effectué va dans la bonne direction : une beta 2 presque finalisée, avec de plus en plus de possibilités, et des actions toujours aussi faciles à mettre en oeuvre.

Par exemple : la prise en charge des processeurs avec technologie Hyper Threading a été très fortement améliorée. Maintenant, lorsqu’on choisi l’affinité sur un CPU, la partie HT correspondant est automatiquement sélectionnée. Un pur bonheur testé avec succès par un habitué de PCInpact (Geek85) sur un Core I7.

J’ai un peu cherché dans le Framework, et au niveau « Processus », ça n’existe pas directement.
Les seuls codes que  j’ai trouvé, et qui soient facilement exploitables, se contentent de mettre tous les threads d’un processus en pause, en utilisant des API Windows. 

Et forcément, c’est le genre de code qui n’est pas totallement « sûr ». En effet, que se passe-t-il si on suspend un thread qui est dans une section critique, alors qu’un autre thread attend un résultat, et que la remise en route des threads ne se fait pas correctement ? Et bien, on obtient un processus figé.

Mon programme « joue » déjà avec la priorité et l’affinité, ce que certains considèrent comme dangereux et devant être réservé au système d’exploitation.

Là, en implémentant possibilité de « mettre en pause » des processus, mon programme risque de rendre instable la machine des utilisateurs, et je ne pense pas que ce soit un bon point.

Alors : pour où contre cette fonctionnalité de mise en pause des processus ?