Discussion :

[adiGuba]

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++

[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.

[Uther]

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é.

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.

[Jidefix]

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?

[zouuc]

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.

[Uther]

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.

[adiGuba]

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...

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é !!!

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 ?

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++

[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

[tchize_]

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[zouuc]

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

[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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[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.

[bulbo]

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

[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

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

[adiGuba]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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)
	}
    }

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++