Créer une méthode avec un timeout

Version imprimable

02/02/2009, 21h20
damien77

Créer une méthode avec un timeout

Bonjour,

j'aimerais savoir comment faire pour générer une méthode qui emet une exception timeout si le temps d'éxécution est trop long ? en effet, je dispose actuellement d'une méthode dont le temps d'éxécution met de 20 à 60 secondes. J'aimerais déclencher une exception au bout d'un temps x et bien sur arrêter le traitement de la méthode mais comment faire ?

merci
02/02/2009, 21h31
tchize_

c'est à toi, dans ta méthode, de mesurer ton temps de calcul et d'arrêter si tu dépasse un délai en lancant, par exemple, une exception. On ne peux pas le faire de l'extérieur de la méthode.
02/02/2009, 21h54
damien77

donc je ne peux rien faire ici ?....
02/02/2009, 22h54
tchize_

si tu veux le faire de l'extérieur, pas possible. En meme temps, tu prend la boucle de ton code qui prend le plus de temps et tu fait des check de temps dedans.
18/02/2009, 16h02
zouuc

Il y a peut-etre moyen de le faire à l'exterieur avec un multi-thread :?
A voir ;)
18/02/2009, 16h12
Uther

Oui mais justement s'il confie a un autre thread la tache de mesurer le délai, alors, il ne pourra pas interrompre directement le thread qui s'occupe du traitement.
18/02/2009, 16h14
moufasa

Bonjour,
comme l'a dit zouuc, je pense qu'il devrait y avoir moyen au moyen d'un thread qui serait lancer juste avant ton instruction bloquante.

Ce thread ne ferais que lancer une exception qui serait a catché dans ta méthode au bout de X temps. Si tu a fini ton traitement avant la fin du temps, il suffit de faire appel à une méthode de ton thread qui ferme celui ci ou qui coupe du moins ton timer.

Le fait que tu catch cette exception coupera l'effet bloquant.

A plus tard

____________________________________________

seulement 10 personnes peuvent comprendre ceci...
18/02/2009, 22h29
tchize_

Citation:

Envoyé par moufasa

Ce thread ne ferais que lancer une exception qui serait a catché dans ta méthode au bout de X temps.

Ca marchera pas, tu va avoir le thread X qui exécute le code bloquant et le thread Y qui déclenche une exception au bout de n minutes. L'exception lancée par Y ne sera jamais vues par X puisque ce sont deux threads différents. Le seul moyen d'arreter X c'est qu'il décide de lui même de s'arrêter, sur base d'une information stockée dans une variable ou à la fin de son traitement.
19/02/2009, 09h11
moufasa

je suis quasiment certain que de l'extérieur il doit y avoir moyen. Mais une des conditions serait que le thread timer prenne en paramètre l'objet "this" qui lui, donnera accès à une méthode pour couper l'effet bloquant de l'objet appelant (par l'intermédiaire d'une exception ou comme tu le dit une variable spécifique à cet arrêt).

ps: Pourquoi lancer deux thread? un seul timer suffirait.
19/02/2009, 09h33
Uther

Citation:

je suis quasiment certain que de l'extérieur il doit y avoir moyen. Mais une des conditions serait que le thread timer prenne en paramètre l'objet "this" qui lui, donnera accès à une méthode pour couper l'effet bloquant de l'objet appelant (par l'intermédiaire d'une exception ou comme tu le dit une variable spécifique à cet arrêt).

Non il n'y a pas de moyen direct d'interrompre un thread depuis un autre.

C'est un problème récurent. Les commandes qui permettent de faire ça ont été dépréciées car source d'erreurs. cf http://java.sun.com/j2se/1.5.0/docs/...precation.html. La seule méthode propre de faire ça est d'utiliser une variable qui indique la demande l'interruption. Le thread a interrompre doit surveiller a intervalle régulier cette variable et s'interrompre lui même.

Au final, implémenter ça dans son cas reviendrait donc a la même chose, en plus compliqué. Le thread devra de toute façon se surveiller lui même a intervalle régulier, qu'il surveille la date ou une demande d'interruption.
19/02/2009, 10h46
adiGuba

Salut,

Citation:

Envoyé par Uther

C'est un problème récurent. Les commandes qui permettent de faire ça ont été dépréciées car source d'erreurs. cf http://java.sun.com/j2se/1.5.0/docs/...precation.html.

En effet en stoppant un thread depuis un autre, on peut laisser la mémoire ou le status d'objet dans un état incohérent, ce qui pourra provoquer des erreurs incompréhensible par la suite...

Citation:

Envoyé par Uther

La seule méthode propre de faire ça est d'utiliser une variable qui indique la demande l'interruption. Le thread a interrompre doit surveiller a intervalle régulier cette variable et s'interrompre lui même.

En général on utilise interrupt() pour cela. Certain méthode gère déjà cela mais il faut également surveiller le statut du thread (cette méthode se contente de passer une valeur "interrupted" de false à true)

Mais pour savoir si cela peut être utilisé ou pas, il faudrait déjà savoir ce que fait le thread... (il y a certaines méthodes bloquantes qui ne gère pas du tout cela :()

a++

mmhh je sais pas si je je peux aider mais il se trouve que durant mon stage que je suis en train d'effectuer j'ai eu à realiser une tache similaire.
Je vais donc poster ici un exemple de code. Mon avis est que le multi-thread permet de faire un equivalent du "timeout" :

Multi-thread : Comment cela fonctionne t-il ?
Il faut savoir qu’un second thread se fait donc dans une nouvelle classe qui hérite de Thread. Dans cette même classe, le code qui sera effectué en tant que sous processus se fait dans un run().
Enfin, il ne faut pas oublier de fermer le thread qui sera appelé.

Le code exemple de la classe principale :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static Document reponse;
public static long patience;
 
private Document getTheResponse()
throws Exception
{ 
   patience = 15000;  //Temps que vous voulez attendre
   reponse = null; //Initialisation de la variable qui sera retournée, à null	
   testThread thread = new testThread();  //Appel du second thread (je ne sais pas si dans ton cas elle est utile damien77 car moi j'y passais des variable pour un constructeur dans mon code original)
   long startTime = System.currentTimeMillis(); //On garde en variable le moment présent
   System.out.println("Veuillez patienter...");
   thread.start(); //Démarrage du second thread
   //Début de la boucle dans laquelle est appelé le code en relation avec le serveur
   while(((System.currentTimeMillis() - startTime) < patience) && (thread.isAlive()))
   { 
      if (patience == 0)
         thread.interrupt(); //Thread ne sera plus alive et donc nous sortons de la boucle
   }
   return reponse; //On retourne la variable qui nous interesse
}

Le code exemple du thread appelé :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class testThread extends Thread //Déclaration d’une nouvelle classe qui hérite de Thread
 
 
public class testThread extends Thread{
 
   public void run() //Le code qui est inscrit dans cette procédure sera effectué comme sous-processus
   {
      try
      {
         Main.reponse = ConnexionServeur(); //reponse de la classe Main prend ce qui est retourné
         if(Main.reponse != null)
         {
            Main.patience = 0; //Patience de la classe main prend null (sortie de la boucle)
         }
         Main.patience = 0; //Patience prend 0 (on sort de la boucle dans ce cas aussi)
     }
     catch(Exception e)
     {
         System.err.println(e.getMessage()); //Affichage d’erreur
     } 
   }
}

J'espere que ça pourra aider :D

19/02/2009, 20h13
damien77

merci pour vos réponses.
zouuc, je viens de tester ta solution mais elle ne marche pas...

Comme je l'ai dit utiliser un Thread est un méthode inutilement compliquée qui necessitera de toute facon de modifier la classe a interrompre.
Pour faire au plus simple, on peut procéder ainsi:
Code:

1 2 3 4 5 6 7 public void methodeLongue throws TimeoutException { final long timeout = System.currentTimeMillis() + 60000; //(60000 ms -> 1 minute) // début du code if( System.currentTimeMillis() > timeout ) throw new TimeoutException(); // suite du code }
Il suffit de placer la ligne qui lève l'exception de manière judicieuse dans une boucle pour que le test soit exécutée régulièrement.

20/02/2009, 10h09
zouuc

mmhh en y reflechissant bien mon code ne correspond p-e pas à ce que tu veux faire. Dans mon cas, c'est juste que si le temps de connexion à un serveur est anormalement long (par exemple le serveur est Out ou Off) à la place d'attendre indéfiniement (ce qui se passait au début) et bien ça quitte l'appli. Dans mon cas ça marche à merveille.
J'avais essayé de realiser ça d'une autre façon (sans appel de thread, et tout se fait dans la classe principale) et ça ne marchait pas pourtant le code était bon.
On ne quittait jamais le while alors que pourtant ça devrait, j'ai essayé avec un multi-thread et ça à marché.

je suis dsl que ça ne fonctionne pas damien77 :(
20/02/2009, 10h34
Jidefix

Le problème avec l'histoire de la variable et du test pour savoir si on arrête le traitement ou pas, c'est que ça ne permet pas d'arrêter le thread si celui-ci est sur une opération bloquante comme un "connect" par exemple.
D'où l'interet du Thread.stop()
Ils sont bien gentils de déprécier des fonctions parce qu'elles sont risquées, mais tant qu'il n'existe pas d'autre solution je dirai qu'on a pas trop le choix non?
20/02/2009, 10h41
Uther

zouuc> Ta méthode utilise un thread séparé et thread.interrupt() pour demander l'interruption du thread qui fait les traitements.
Ça revient a peu près à la même chose que la variable commune dont j'avais parlé.
La différence avec la variable commune est que certaines fonctions de Java bloquantes comme la lecture de fichier, synchronisation, ... vont lever une exception et donc se débloquer.

Cependant interrupt() n'interromps pas directement le Thread. Il positionne juste une variable interne à true pour indiquer que le thread a demandé d'être interrompu, a la charge au programmeur de vérifier cet état et d'agir en conséquence comme le font la plupart des fonctions bloquantes de java. Le thread qui exécute l'opération longue devra donc surveiller l'état du thread via quelquechose du genre if (Thread.interrupted()) throw new TimeoutException(); exécuté a intervalle régulier.

Donc au final le problème reviens au même qu'avec mon exemple monothread : trouver une boucle, ou le test sera effectué régulièrement.
20/02/2009, 10h45
adiGuba

Citation:

Envoyé par Jidefix

D'où l'interet du Thread.stop()

Quel intérêt à rendre potentiellement instable une application ?

Citation:

Envoyé par Jidefix

Ils sont bien gentils de déprécier des fonctions parce qu'elles sont risquées, mais tant qu'il n'existe pas d'autre solution je dirai qu'on a pas trop le choix non?

Il existe d'autre solution, comme cela a déjà été indiqué dans ce post.

Donc s'il y a toujours un problème il faudrait le spécifier avec le code qui va avec...

a++
20/02/2009, 10h48
Jidefix

Citation:

Envoyé par Uther

La différence avec la variable commune est que certaine fonctions de Java boquantes comme la lecture de fichier, synchronisation, ... vont lever une exception quand le thread est interrompu et donc ce débloquer.

Tiens je connaissais pas ça, y-a-t-il moyen de savoir si une fonction d'une API externe sera interrompue par un "interrupt" du coup? (je veux dire, sans tester)
20/02/2009, 11h05
Jidefix

Citation:

Envoyé par adiGuba

Quel intérêt à rendre potentiellement instable une application ?
Il existe d'autre solution, comme cela a déjà été indiqué dans ce post.

Ben la seule autre solution qui semble applicable est le coup de l'interrupt, mais apparement même ça ça risque de ne pas marcher sur certaines méthodes.
On a le probleme pour des fonctions de connexions à des serveurs via les protocoles FTP, HTTP, etc...
Il arrive que les fonctions de login restent bloquées indéfiniment. Je ne connaissais pas le principe de l'interrupt, on va regarder si ça pourrait marcher...
20/02/2009, 11h10
adiGuba
Citation:

Envoyé par Jidefix

On a le probleme pour des fonctions de connexions à des serveurs via les protocoles FTP, HTTP, etc...
Il arrive que les fonctions de login restent bloquées indéfiniment. Je ne connaissais pas le principe de l'interrupt, on va regarder si ça pourrait marcher...

Il y a plusieurs solutions :
- Passer par les SocketChannel qui génère une exception si un interrupt() survient pendant une méthode bloquante.
- Ou tout simplement utiliser setSoTimeout() pour que le Timeout soit gérer directement par les méthodes de la socket...
Après si tu utilises une API externe il faut voir si elle te permet de gérer cela et comment...

a++
20/02/2009, 13h28
tchize_

le Thread.stop(), c'est la solution du programmeur qui veux pas chercher à gérer proprement ses opération longue et qui viens après pleurer parce qu'il a un comportement bizzare a son application.
20/02/2009, 13h40
Uther

Citation:

Envoyé par Jidefix

Tiens je connaissais pas ça, y-a-t-il moyen de savoir si une fonction d'une API externe sera interrompue par un "interrupt" du coup? (je veux dire, sans tester)

Il faut regarder dans la javadoc la liste des Exceptions levées par la méthode bloquante. S'il y a des exceptions levées par une demande d'interruption du thread, c'est généralement précisé.

Citation:

On a le probleme pour des fonctions de connexions à des serveurs via les protocoles FTP, HTTP, etc...

Il me semble que Thread.interrupt() ne lève pas d'exception sur les fonctions de base des sockets. Mais heureusement il suffit de fermer la socket pour interrompre les fonctions bloquantes.
20/02/2009, 14h16
Jidefix

Citation:

Envoyé par tchize_

le Thread.stop(), c'est la solution du programmeur qui veux pas chercher à gérer proprement ses opération longue et qui viens après pleurer parce qu'il a un comportement bizzare a son application.

La vie a l'air vachement simple quand on lit ce genre de post.
Figure toi que dans la vie il existe des API externes, qu'on peut être obligé d'utiliser parce que c'est la norme, et qui ne gèrent pas forcément ces "opérations longues", qui ne sont pas forcément des boucle for. Il faut donc gérer une fonction boite noire dont tout ce qu'on sait est qu'elle peut etre trop longue, et qu'elle n'a pas forcément prévu de timeout.
Tout le but de cette discussion est justement de trouver des astuces pour le gérer, mais sauf si j'ai mal compris un post, ce dont je m'excuse à l'avance, aucune solution universelle n'a été proposée.
Le stop reste donc la seule solution d'après ce que je conclus de ce topic.

Sinon j'ai une autre question: quand on dit que le stop peut créer des instabilités en laissant des variables dans un état incohérent, cela signifie juste que les variables affectées par le thread deviennent alors fonctionnellement incohérentes, ne suffit-il donc pas de vérifier l'état de ces variables lorsque l'on doit procéder à ce genre d'interruption?
20/02/2009, 14h29
zouuc

Citation:

Il faut donc gérer une fonction boite noire dont tout ce qu'on sait est qu'elle peut etre trop longue, et qu'elle n'a pas forcément prévu de timeout.

Le thread.interrupt() peut s'y appliquer justement non? (je parle par rapport à mon code).

Je ne comprend plus trop :?

Damien77 pourrais-tu nous dire ce que tu veux executer durant le décompte que tu veux effectuer stp ?
Je voudrais t'aider et aussi comprendre pourquoi la methode que j'ai proposée ne fonctionnerais seulement dans certains cas.
20/02/2009, 14h44
Uther

Citation:

Envoyé par zouuc

Le thread.interrupt() peut s'y appliquer justement non? (je parle par rapport à mon code).

Je ne comprend plus trop :?

Damien77 pourrais-tu nous dire ce que tu veux executer durant le décompte que tu veux effectuer stp ?
Je voudrais t'aider et aussi comprendre pourquoi la methode que j'ai proposée ne fonctionnerais seulement dans certains cas.

Tout dépend si le ConnexionServeur() de ton exemple gère l'interruption ou non.

De plus ton code à l'air, au mieux incomplet, au pire faux. Il manque le constructeur à 2 paramètres auquel tu fais appel. De plus l'interrupt() n'a lieu que si tout se passe bien alors qu'il devrait avoir lieu au contraire si la fonction bloque.
20/02/2009, 14h59
adiGuba

Citation:

Envoyé par Jidefix

Figure toi que dans la vie il existe des API externes, qu'on peut être obligé d'utiliser parce que c'est la norme, et qui ne gèrent pas forcément ces "opérations longues", qui ne sont pas forcément des boucle for. Il faut donc gérer une fonction boite noire dont tout ce qu'on sait est qu'elle peut etre trop longue, et qu'elle n'a pas forcément prévu de timeout.

Le problème vient alors de l'API externes...

Citation:

Envoyé par Jidefix

Tout le but de cette discussion est justement de trouver des astuces pour le gérer, mais sauf si j'ai mal compris un post, ce dont je m'excuse à l'avance, aucune solution universelle n'a été proposée.
Le stop reste donc la seule solution d'après ce que je conclus de ce topic.

Il n'y a pas de solution universelle... et surtout pas stop() !!! Ces recommandations sont indiqué dans la documentation officiel : http://java.sun.com/javase/6/docs/te...precation.html
Après libre à toi de faire comme tu veux, mais ce n'est pas sans risque...

Il y a bien plusieurs solutions, mais pour donner la solution à un problème spécifique il faudrait déjà le connaitre : on ne sait toujours pas quel code (perso ou librairie) doit être stoppé !!!

Citation:

Envoyé par Jidefix

Sinon j'ai une autre question: quand on dit que le stop peut créer des instabilités en laissant des variables dans un état incohérent, cela signifie juste que les variables affectées par le thread deviennent alors fonctionnellement incohérentes, ne suffit-il donc pas de vérifier l'état de ces variables lorsque l'on doit procéder à ce genre d'interruption?

Comment tu vérifies cela ? Et comment tu garanties que cela est bien fait ?

:arrow: En général la JVM et les APIs standard privilégient le fail-fast. C'est à dire qu'elle préfèrera planter un peu plus tôt en prévision d'une possible erreur, plutôt que d'utiliser des "rustines" pour tenter de les éviter au maximum, pour finir par provoquer une erreur aléatoire difficilement débugable...

a++
20/02/2009, 15h11
bulbo

J'arrive après la bagarre mais voilà une solution qui se base sur le cas d'une API externe qui ne voudrais pas s'interrompre par exemple.

1 - Au lieu de tenter la connexion depuis le thread courant, la faire depuis un autre Thread

2 - S'arranger pour ne rien lier de l'application à cette connexion tant qu'elle n'est pas établie sans timeout

3 - Le thread courant sera en wait(timeout) et à la fin du wait si la connexion n'est pas effectuée il balance une exception, et positionne une variable dans le thread de connexion pour lui dire de balancer la connexion aux orties si jamais elle fini par se faire.

4 - Quand la connexion est faite on enregistre la connexion ou il faut pour que le programme continue et on notifie le thread courant qui est toujours sur son wait.

Avec cette implémentation si la connexion échoue après un temps indéfinie, elle le fera dans un thread dont plus personne ne s'occupe et n'aura aucun impact sur l'appli. Et le timeout claquera bien quand il faudra..

Bulbo ;)
20/02/2009, 15h22
tchize_
Citation:

Envoyé par Jidefix

La vie a l'air vachement simple quand on lit ce genre de post.

Ben oui désolé, mais c'est comme ça. La manière dont je l'éai ditt était peut-être un peu agressive. Les api Stop() ont été retirées pour une bonne raison et les utiliser provoque beaucoup plus de problèmes qu'il n'en résoud. D'autre part, je ne connais que peu de language qui permettent de tuer un Thread sans son consentement, et sans tuer l'application qui l'utilise, et pour cause, ca fout le bordel.

J'ai pas dit que c'était facile d'utiliser autre chose que les stop(), mais le stop() c'est touche pas à ça sinon tu le regrettera inévitablement. Si l'api boite noire peut se bloquer indéfiniment, alors elle est buggée et doit être corrigée, ou faudra s'orienter vers un autre fournisseur pour l'api en question, ou faudra assumer le fait qu'elle bloque et qu'on sais rien y faire (au pire on laisse trainer le thread dans un coin de la jvm......)

En voulant tuer le code de l'extérieur, tu va dire merde à ton api, briser sauvagement les principes d'encapsulation et tu va terminer avec du code probabiliste (ça marche "généralement sauf parfois",). Tu sera quand même bon pour redémarrer ton application après -> si c'est pour en arriver là, autant redémarrer direct l'application.

Citation:

quand on dit que le stop peut créer des instabilités en laissant des variables dans un état incohérent, cela signifie juste que les variables affectées par le thread deviennent alors fonctionnellement incohérentes, ne suffit-il donc pas de vérifier l'état de ces variables lorsque l'on doit procéder à ce genre d'interruption?

Ces instabilité peuvent se trouver dans n'importe quel objet en cours de manipulation anodine par le thread au moment du kill. On peux donc casser

- des collections utilisées par le thread pile à ce moment là
- des objets en cours d'incrémentation, filtrage ou autre
- le classloader si il était occupé de charger une classe pour le compte du thread (et on passe très souvent dans le classloader)
- les classe de base de l'api java si le thread appelait une méthode statique sur une de ces classes (charger un driver jdbc, enregistrer un gestionnaire d'url, maintenir la liste des sockets ouvertes à fermer en quittant, cache de ImageIO, etc)

bref, tu peux casser tout et n'importe quoi dans ce qui est encapsulé et que t'es pas censé voir au niveau de l'api de base java, et pas uniquement les variables utilisées par le thread.. Les résultats sont complètement aléatoire. en effet, un simple code anodin comme celui-ci
Code:

1 2 3 4 5 private List l; ..... List newList = .... l = newList;
peux déjà casser la référence l, et pourtant, quand on lit ce code, on s'attendrais pas à choper un ThreadDeathException :) Et des codes anodins qui ne s'attendent pas à être interrompu, y en a presque à toutes les ligne d'une application. Et pour cause, si on devait gérer constament le kill du thread, le code ne ressemblerais plus à rien. Enfin, tuer le thread avec ce genre d'exception pose des problème au niveau des try{} catch. Doit-on autoriser le catche de cette exception ? Si oui, on peut alors refuser le kill du thread, et l'agressivité du stop() est complètement déplacée. Sinon, on a alors des try{} catch finally dont on a plus la garantie qu'il catchent ou passent dans le finally -> facheux du point de vue développement.
20/02/2009, 15h25
Uther

bulbo> Ta méthode ne me semble pas suffisante. On risque de se retrouver avec autant de thread zombies que de tentatives de connexion échouées.

Lancer la connexion dans un thread séparé, ne dispense pas d'essayer autant que faire ce peu de libérer les ressources en cas d'échec(fermer, les socket, fichiers, ...) et de terminer le thread.
20/02/2009, 15h35
zouuc

Citation:

Il manque le constructeur à 2 paramètres auquel tu fais appel

Au temps pour moi Uther ^^ A force d'avoir changé mon code, ici je me rend compte que je n'en ai pas besoin, mais dans le cas de mon appli j'en ai besoin et ça porte à confusion forcement ^^. (j'ai au passage modifié en conséquence mon exemple montré page 1)
En ce qui concerne le thread.interupt(), je l'avais oublié aussi je m'en excuse grandement :oops:

Ah oui je n'avais pas vu que le stop() pouvait carrément ruiner des variables inconnue mais nécessaires...
A noter que je suis jamais tombé sur ce genre d'erreur, mais faut dire que j'en fait pas tous les jours non plus :?

Après lecture de l'excellente page de sun, j'ai noté cette partie là:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 private volatile Thread blinker; public void stop() { blinker = null; } public void run() { Thread thisThread = Thread.currentThread(); while (blinker == thisThread) { try { thisThread.sleep(interval); } catch (InterruptedException e){ } repaint(); } }
Si je comprends bien (je n'ai jamais utilisé volatile), ce code se contente de faire monThread=null, mais ça veut juste dire qu'on perd la référence sur le thread, je vois pas ce que ça apporte?

20/02/2009, 15h52
Uther

L'interet n'est pas de perdre la référence mais que la condition du while (blinker == thisThread) devienne fause. Donc la boucle principale se termine, et le thread avec elle.

Le volatile indique que la variable peut être modifiée de manière concurrente par plusieurs thread, ce qui évite certaines optimisations problématiques.
20/02/2009, 15h59
bulbo

Citation:

Envoyé par Uther

bulbo> Ta méthode ne me semble pas suffisante. On risque de se retrouver avec autant de thread zombies que de tentatives de connexion échouées.

Lancer la connexion dans un thread séparé, ne dispense pas d'essayer autant que faire ce peu de libérer les ressources en cas d'échec(fermer, les socket, fichiers, ...) et de terminer le thread.

Je n'ai jamais dit qu'il ne fallait pas tenter un truc pour friter la connexion qui ne nous intéresse plus, au contraire mais mon exemple (et je l'ai spécifié au début) ce place dans un contexte ou c'est une lib externe qui bloque et qu'elle ne te propose pas d'option pour libérer proprement les ressources.

Alors tu fais tout les threads interrupt du monde si tu veux mais ça ne te libère pas non plus un connexion bloqué tu ne sais comment et non-interruptible par exemple. La différence c'est que tu auras X Thread interrompus au lieu de X thread bloqués et ne faisant rien .. limite kif kif bourrique..

Bulbo ;)
20/02/2009, 16h02
Jidefix

D'accord, donc ça ne résout pas notre problème qui est que les deux seules manières d'arrêter proprement un thread consiste soit à lui dire poliment à travers une variable en esperant que ce thread aie l'occasion de tester cette variable, soit à l'interrompre, ce qui ne marche pas pour toutes les fonctions...

Au final blocage d'une fonction donnée qui ne gère pas les interruptions et les timeout = fin de l'application et si possible réécriture de la fonction :aie:

En tout cas merci, j'ai appris un tas de trucs aujourd'hui ;)

Citation:

Envoyé par Jidefix

Ah oui je n'avais pas vu que le stop() pouvait carrément ruiner des variables inconnue mais nécessaires...
A noter que je suis jamais tombé sur ce genre d'erreur, mais faut dire que j'en fait pas tous les jours non plus :?

Et le problème c'est surtout que cela n'est pas systématique...

Il est possible que cela ne fasse rien dans 99.99% des cas... cela dépend de plein de chose dont l'architecture matérielle, l'OS, le séquencement des threads, le moment exact du stop...
Mais le jour où tu tombes sur le 0.01% restant tu vas passer des nuits blanches à essayer de chercher d'où vient l'erreur. Et comme le dit la doc l'erreur peut survenir plusieurs heures après le stop du thread ! Va faire le rapprochement entre tous cela :aie:

Citation:

Envoyé par Jidefix

Si je comprends bien (je n'ai jamais utilisé volatile), ce code se contente de faire monThread=null, mais ça veut juste dire qu'on perd la référence sur le thread, je vois pas ce que ça apporte?

Ce code se contente de rendre caduc la condition du while, ce qui fait que le thread se terminera à la prochaine itération...

Perso j'aurais plutôt utilisé un booléen (je trouve que c'est plus clair) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 private volatile boolean alive = true; public void stop() { alive = false; } public void run() { while (alive) { try { Thread.sleep(interval); } catch (InterruptedException e){ } repaint(); } }
Le volatile indique simplement à la JVM que la variable peut être modifié depuis des threads différents, et qu'il faut donc re-vérifier sa valeur à chaque accès. Sans volatile il est possible (mais pas obligatoire) que la JVM optimise le code en n'accédant réellement qu'une seule fois à la valeur (et ne prennent pas en compte ses modifications depuis un autre thread).

Mais plutôt que de passer par une variable et une méthode, on peut directement utiliser interrupt() :
Code:

1 2 3 4 5 6 7 8 9 10 public void run() { try { while (Thread.interrupted()) { Thread.sleep(interval); repaint(); } } catch (InterruptedException e) { // interrupted (fin du thread) } }
:arrow: L'avantage c'est que si l'interruption survient pendant une méthode bloquante qui gère cela (sleep() dans notre cas), le thread s'arrêtera immédiatement ;)

a++