Donc on pourra mettre des print un peu partout pour surveiller ce qui se passe.
Debugger un programme multithreadé temps réel à coup de print ? BONNE CHANCE.
Sur ce genre de chose, le simpel fait d'ajouter un print change le comportement du programme/la priorité des threads et leur ordre d'execution.
L'idéal pour ce genre de chose c'est de pouvoir faire tourner le programme sur une VM, ou au moins de pouvoir "geler" uen partie de la machine réelle pour la dissequer calmement...
Les autres approches ont tendances à générer encore plsu de bugs qu'elles n'en résolvent.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging
J'imagine que certains threads (système ou programmatiques) viendront mettre à jour les booléens de temps en temps non ?
Tous les problèmes de debugging arrivent à ce moment là (gestion de ressources, condition de courses, passage de messages foirés etc.)
[^] # Re: C'est interressant, mais...
Posté par Jerome Herman . En réponse au journal Le langage de mes rêves. Évalué à 10.
Debugger un programme multithreadé temps réel à coup de print ? BONNE CHANCE.
Sur ce genre de chose, le simpel fait d'ajouter un print change le comportement du programme/la priorité des threads et leur ordre d'execution.
L'idéal pour ce genre de chose c'est de pouvoir faire tourner le programme sur une VM, ou au moins de pouvoir "geler" uen partie de la machine réelle pour la dissequer calmement...
Les autres approches ont tendances à générer encore plsu de bugs qu'elles n'en résolvent.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging
J'imagine que certains threads (système ou programmatiques) viendront mettre à jour les booléens de temps en temps non ?
Tous les problèmes de debugging arrivent à ce moment là (gestion de ressources, condition de courses, passage de messages foirés etc.)