killer et redémarrer un thread

Bonjour,

Je développe un application sous Delphi 5 qui tourne avec 19 threads et il arrive parfois que pour une raison que j'ignore un de mes threads plante. Je voulais savoir s'il y avait un moyen de détecter le "plantage" du thread, puis de le killer sauvagement et de le redémarrer.

Je pense faire un truc du genre :

Code:

---

1 2 3 4 5

if not Assigned(MonThread) then begin kill(MonThread) //je sais pas ce qu'il faudrait appeler ici MonThread := MyTypeThread.Create(...); end;

---

pour les 19 threads dans un 20ème thread indépendant.

Merci pour vos réponses,

rerou

TerminateThread !

Sinon, j'ai eu des problèmes de thread instable, souvent une erreur de ma part genre un next oublié dans une boucle (celle-ci ne survenant qu'après un heure de traitement dans le process donc dur à trouver) ou alors un composant FTP qui bloque lamentablement !

un thread bloqué ça peut venir d'une mauvaise utitilisation d'un ReadWriteSynchronizer ou d'une Section Critique provoquant un Dead Lock !

Vérifie bien la stabilité de ton code, ne laisse pas les exceptions en sortir !
Perso, je logguais tout, du try except en masse !
A la moindre erreur logique, j'avais une procédure de rollback (faite à la main)
Les exceptions étaient rarissimes voire inexistantes sauf plantage irrémédiable

19 Threads, c'est bcp, tu as besoin d'autant de traitement en parallèle ?

J'avais un pilotage de robot qui tournait de 8h à 20h, près de 500 000 messages TCP\IP échangés, près de 3 000 000 de SQL, 1000 fichiers envoyés sur FTP et l'affichage temps réel de l'état de l'automate de tri !
Je n'avais qu'un thread pour la DB, deux thread pour l'émission tcp sur 2 ports, un thread pour l'import ftp depuis as400 et un thread pour l'export ftp, ça en fait seulement 5

En mode full trace, je générais 100 Mo de log par heure !
je peux te dire que j'avais blindé la logique du programme pour anticiper les erreurs, la seule que je n'ai jamais pu éliminer, ce fut le plantage du BDE, au bout de 28h (de traitement, ça pouvait faire 72h avec trois passe de 12h, le 3jour, plantage après presque 10 000 000 SQL, crash ! écran bleu, programme mort !
Je n'ai jamais trouvé la réponse, ayant dû réécrire tout ce projet en Delphi 6 en un mois alors qu'il m'en avait fallu deux pour le faire en Windev 7.5, je n'avais pas le temps de trouver autre chose que BDE\Paradox mes expériences avec IB m'avait laissé un gout trop amère !

j'avais prévenu mon boss que le programme Windev ne supportait pas la charge selon mes tests (rien que le listen de deux ports tcp, ça leur faisait tomber si les connexions étaient trop rapprochées).
Il m'a répondu : "ne dénigre pas l'outil de développement de notre société, toi et ton delphi, grrrr ..."


Chaque thread contient un integer, qu'il remette à zéro à chaque tour dans le Execute (en fait à chaque pop dans la thread FIFO)
Un timer (sur 100 ms) se charge de faire Inc sur chaque integer, ensuite, j'avais un tableau de bord, en vert de 0 à 2, en orange de 3 à 10, rouge de 10 à 20, noir indiquant un restart du thread, blanc un echec de restart !

A toi de voir, la tolérance de temps de traitement !

Salut,

Oui je suis obligé d'en avoir autant parce que j'ai 15 ports de communication UDP donc 15 threads juste pour ça et donc seulement 4 pour les traitements. Sinon qu'est-ce qu renvoie ThreadTerminate exactement ?

Merci pour ta réponse en tout cas

MSDN TerminateThread
, faudrait lire la doc, même celle de Delphi Classes.TThread.Terminate

Perso, j'utilisais le TServerSocket, j'avais deux Ports sur ce projet et en général un seul client sur chaque port !

Pour un autre projet, j'avais aussi deux Ports, mais environ 10 clients !
Je laissais le mode NonBlocking et l'event OnRead !
Dans l'event je ne traitais pas le message, je l'ajoutais dans une threadlist A
un 1er thread se chargeait d'analyser le paquet (gestion de fragmentation ...), une fois un message complet, je le découpais dans un record, ce dernier dans une autre threadlist B et j'ajoutais un ACK ou NAK dans un 3eme threadlist C
un 2nd thread se chargeait de traiter les messages de B, cela manipulait la DB, parfois cela ne faisait qu'un routage de message vers un autre client, puis ajouter un record dans C
un 3eme thread se chargeait de traiter C pour générer les messages TCP vers l'un des 10 clients (le ACK, NAK ou Record de B, contenait l'ID du socket ayant provoqué le message d'origine, indispensable pour savoir à qui on doit répondre !)

Pour l'UDP, j'ignore quels composants tu utilises !
Si tu as un mode nonblocking tente le
Sinon, tu peux mettre plusieurs sockets dans un même thread, suffit juste de les lire tour à tour (genre un timeout de 10ms pour chaque), tout dépend le débit !
En plus, tu as peut-être de l'écriture, donc il te faut relacher la lecture pour envoyer les données !?

Mais on peut effectivement ignorer ces 15 threads UDP, après tout, je suppose qu'il passe la majorité du temps à attendre de la donnée, tu peux effectivement mettre un timeout de 100ms, juste pour envoyer une notification genre "no data" et être rassuré sur leur état
Faudrait vérifier mais je suppose que la carte gère un tampon, cela accumule la donnée, si tu envoi un 1 Mo côté client tu reçois 8Ko par 8ko sur le serveur ?

En TCP\IP, tu aurais encore plus de thread, en UDP, contrairement au TCP, il n'y a pas de listen, si je me trompe pas, en TCP, si tu as 15 ports, il te faut déjà 15 listen, donc 15 threads (implicite du TServerSocket), alors si tu as 1 client par port, cela fait déjà 30 threads, ...

A quoi cela sert d'avoir 15 Ports ?
Rien n'empêche d'avoir 15 clients sur un seul Port !
Toujours ton multicast ? c'est étrange, je ne connais pas trop comment cela fonctionne mais tu gères vraiment du multicast avec groupe et abonnés de groupe sur une IP de groupe entre 224.0.0.0 à 239.255.255.255

Que font les 4 threads de traitements ?

Les threads de traitement sont des threads de conversion car je reçois des images Bayer et je dois les afficher en RGB888 ou d'affichage.
Sinon en ce qui concerne les ports, j'ai pris le projet en cours donc je ne pourrais pas te dire pourquoi 15 ports mais je pense que c'est par facilité car on a définit des types de trame et donc un type de trame va sur un port.
Mais à la limite ceux-la ne plantent pas, ils ne font qu'écouter un port et remplir des buffers ou balancer le contenu d'un buffer sur un port. Je pense que le plantage vient des 4 autres et ceci est vraiment aléatoire et très difficile à débugguer.

d'où "try except" et log !

exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

try FunctionName := self.ClassName + '.LaMethodeBidule'; // selon la version tu as du code intégré qui le fourni ou de la bidouille ASM + Assertion   SectionName := 'Etape 1'; ... du code   SectionName := 'Etape 2'; ... du code   ...   except on E: Exception do OutputDebugString(PChar(Format('%s - %s : %s = %s', [FunctionName, SectionName, E.ClassName, E.Message]))); end

---

;

OutputDebugString c'est uniquement en Debug dans le Journal d'évènement, tu peux écrire dans un fichier à la place, je te laise faire ta fonction de Log

Tu fais cela un peu partout ou tu penses que ça plante !

Comme souvent dans le multi-thread en pas à pas ça fonctionne mais pas lorsque ça tourne à fond !
Avec ce log tu pourras affiner la Section de code, jusqu'à trouver les codes à corriger pour la stabilité !!

Le soucis du try-except c'est qu'il est plutôt long et j'ai une contrainte temps-réel donc je vais essayer ça mais j'ai peut que ça me plombe.

Merci bien en tout cas

Quel est le rapport entre "contrainte temps-réel" et "peur que ça me plombe" ?
Tu veux un programme robuste, tu dois le rendre résistant à l'erreur, soit en prévenant les erreurs par un code "prédictif" (c'est pas le bon mot, mais il y a un terme pour ça) soit réagissant aux erreurs par un code gérant les exceptions !

Citation:

---

Le soucis du try-except c'est qu'il est plutôt long

---

Long comment ça, ne me dit pas que tu as codé une énorme de fonction de 1000 lignes sans aucun découpage en sous-fonction ou même une certaine répartition des taches avec une approche Patter\POO

J'ai fait des programmes avec "contrainte temps-réel", et j'en fait encore !
un thread ne plante pas par hasard !
tu as fait une erreur de développement qui conduit à un DeadLock ou provoque une erreur non géré !
Tu DOIS corriger cela, les try-except, pas un mais des centaines, au moins un dans chaque fonction pour augmenter la précision de la traçabilité, une fois ce travail de log effectué, tu pourras débuggueur et corriger l'anomalie !
le try except n'est pas la solution c'est un outil seulement !

Citation:

---

Envoyé par ShaiLeTroll

le try except n'est pas la solution c'est un outil seulement !

---

+1 :ccool: