Discussion :

[nibor2luxe]

Bonjour,

Je suis en gros dans le cas suivant :

class MonThread extends Thread {
MonThread() {}
public void run() {
try {
// instructions avant commande bloquante
Thread.sleep(10000);
// instructions après commande bloquante
}
catch(InterruptedException ie) {}
}
}

En réalité dans mon cas à la place de sleep() j'ai une fonction qui fait tout plein de chose et qui à un temps d'exécution aléatoire.

Je voudrais à n'importe quel moment stopper ce Thread. J'ai pensé à la solution qui consiste à créer une fonction qui lève une interruption pour rentrer dans le catch :

class MonThread extends Thread {
private boolean fin = false;
MonThread() {}
public void run() {
try {
// instructions avant commande bloquante
testFin();
Thread.sleep(10000);
testFin();
// instructions après commande bloquante
}
catch(InterruptedException ie) {}
}
public void testFin() throws InterruptedException {
if (fin == true) {
throw new InterruptedException();
}
}
public void signalerFin() {
fin = true;
}
}

Cependant l'exception n'est levée qu'après la fin de l'exécution de mon instruction bloquante. Ce qui dans mon cas n'est pas bon car je voudrais qu'au moment où j'ai décide de stopper mon Thread, il s'arrête, et pas qu'il s'arrête à la fin d'un instruction ayant un temps d'exécution aléatoire.

Si vous avez des idées, faite passer svp
dieZ

[dinobogan]

Est-ce que c'est une instruction spécifiquement longue ou un algo complexe qui effectue des milliers d'instructions simples ?

[nibor2luxe]

Est-ce que c'est une instruction spécifiquement longue ou un algo complexe qui effectue des milliers d'instructions simples ?

Je n'en ai pas la moindre idée. C'est une méthode : executeTarget() de la classe Project de l'api ANT
Quelle était ton idée ?

[dinobogan]

Je n'en ai pas la moindre idée. C'est une méthode : executeTarget() de la classe Project de l'api ANT
Quelle était ton idée ?

Elle tombe à l'eau
Avec des milliers d'instructions simple, c'était de faire un test régulièrement pour savoir si le Thread doit s'arrêter.

[nibor2luxe]

okay, c'est justement la méthode que j'énoncais dans mon post est qui n'est pas applicable dans mon cas

[nibor2luxe]

up plz !

[elmor]

Et si tu fais une Thread.interrupt () ?

Sinon, si tu veux arrêter ton application, tu peux déclarer ton thread en tant que daemon setDaemon(true) et ainsi tu n'auras pas besoin d'attendre la fin de ce thread pour arrêter ton application.

[Faiche]

Et si tu fais une Thread.interrupt () ?

Sinon, si tu veux arrêter ton application, tu peux déclarer ton thread en tant que daemon setDaemon(true) et ainsi tu n'auras pas besoin d'attendre la fin de ce thread pour arrêter ton application.

ça c'est contourner le problème.

Puis après, si le truc se termine jamais, on se retrouve avec 2000 zombies.

Moi je fais qqch de pas très joli : je me débrouille pour faire sauter l'instruction bloquante (genre quand tu fais un read sur un socket, si tu fais sauter la socket, ça fait sauter le thread)

Mais je suis preneur pour une nouvelle idée.

[Duc Lebowski]

je voudrais qu'au moment où j'ai décide de stopper mon Thread, il s'arrête

J'ai du rater un truc...

Ca ?

Code :

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

1
2
3
4
5
6
7
8
9
class Main
{
    private Thread th = new Thread(new MonThread());
 
    public void momentOuJAiDécidéDeStopperMonThread()
    {
        th.interrupt();
    }
}

[DevTeam_]

J'ai du rater un truc...

Je pense qu'il cherche un moyen de dézinguer une thread à n'importe quel moment. Ex, une requête SQL qui met 10 plombes à s'exécuter, ...

[Duc Lebowski]

Je suis très loin d'être un pro des threads, mais je tente ma chance...

Ca ?

Code :

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

1
2
3
4
5
6
7
8
class Main
{
    public static void main(String[] args)
    {
        // lance AppThread et le tue s'il est encore actif au bout de 10 secondes
        new Thread(new ThreadListener(new AppThread(), 10)).start();
    }
}

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
18
19
20
21
22
23
24
25
26
27
28
29
30
class ThreadListener extends Thread
{
    private Thread _th;
    private long startedAt = -1;
    private int _timeout = -1;
 
    ThreadListener(Thread th, int timeout)
    {
        _th = th;
        _timeout = timeout;
    }
 
    public void run()
    {
        _th.start();
       startedAt = System.currentTimeMillis();
       while(_th.isAlive() && System.currentTimeMillis()-startedAt < 1000*_timeout)
        {
            // dors 1 sec
            try {Thread.sleep(1000);}
            catch (InterruptedException e) {e.printStackTrace();}
        }
        if (_th.isAlive())
        {
            System.out.println(ThreadListener.class.getSimpleName()+" : "+
                  _th.getName()+" a vécu trop longtemps et doit mourir");
            _th.interrupt();
        }
    }
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class AppThread extends Thread
{
    public void run()
    {
        try {
            // en réalité là je fais ma vraie action
            Thread.sleep(20000);
        }
        catch (InterruptedException e) {
            System.out.println(AppThread.class.getSimpleName()+" : quelqu'un m'a tué");
        }
    }
}

=> donne :

Code :

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

1
2
ThreadListener : Thread-0 a vécu trop longtemps et doit mourir
AppThread : quelqu'un m'a tué

[Uther]

Tu te demandais peut-être pourquoi tu catchais l'Interupted Exception? Et bien parce qu'elle est faite exactement pour résoudre ton problème

Mais il ne faut essayer de magouiller pour la déclencher toi même mais le faire via interrupt() de la classe Thread(donc de ta classe principale)

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
class MonThread extends Thread {
MonThread() {}
  public void run() {
    try {
      // instructions avant commande bloquante
      Thread.sleep(10000);
      // instructions après commande bloquante
    }
    catch(InterruptedException ie) {
    }
  }
 
  public void signalerFin() {
    this.interrupt();
  }
}

[divxdede]

La méthode interrupt() ne léve une exception que si a ce moment là le thread est bloqué sur une méthode dite interruptible (exemple Thread.sleep).
Si la méthode bloquante n'est pas interruptible, l'appel à interrupt ne fera que placer un flag à true.

Cf méthode Thread.interrupt()

[Faiche]

Tu te demandais peut-être pourquoi tu catchais l'Interupted Exception? Et bien parce qu'elle est faite exactement pour résoudre ton problème

Mais il ne faut essayer de magouiller pour la déclencher toi même mais le faire via interrupt() de la classe Thread(donc de ta classe principale)

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
class MonThread extends Thread {
MonThread() {}
  public void run() {
    try {
      // instructions avant commande bloquante
      Thread.sleep(10000);
      // instructions après commande bloquante
    }
    catch(InterruptedException ie) {
    }
  }
 
  public void signalerFin() {
    this.interrupt();
  }
}

J'ai du mal comprendre la feinte :

L'idée quand on crée notre thread, c'est de pas s'amuser a coller des sleep partout.

Or, il me semble que seul le sleep craque quand on interrupt() (d'où l'interrupted exception).

Si on a aucune fonction qui lache explicitement une interrupted exception, c'est pas possible de créer le catch dans le vide (du moins sous eclipse).

Du coup, ça me semble aussi louche que la premiere solution qui consistait à demander dans tous les sens "c'est bon la ? je m'arrete ou je continue ?"

[adiGuba]

Salut,

Or, il me semble que seul le sleep craque quand on interrupt() (d'où l'interrupted exception).

Non sleep() n'est pas le seul à renvoyer une InterruptedException, il y a aussi un grand nombre de méthodes qui touche de près ou de loin à la synchronisation : http://javasearch.developpez.com/sun...Exception.html

A noter également qu'il existe les InterruptibleChannel qui réagissent aux interruption...


Bref l'interrupt() permet de stopper plusieurs traitement (mais généralement pas les flux standard).

Du coup, ça me semble aussi louche que la premiere solution qui consistait à demander dans tous les sens "c'est bon la ? je m'arrete ou je continue ?"

En fait il faut cumuler les deux :

• Lorsqu'on utilise un méthode interruptible, il est bon de vérifier manuellement le statut "interrupt" afin d'éviter d'attendre pour rien (un exemple : tu reçois l'interrupt juste avant une attente bloquante cela ne sert à rien de faire l'attente).
  
• Lorsqu'on fait un traitement long qui n'est pas interruptible, il peut être utile de vérifier ce statut régulièrement afin d'éviter de continuer un traitement inutile et de terminer le thread proprement...

a++

[bulbo]

Dans son cas n'ayant pas la main sur le traitement il a pas trop le choix .. dans un cas similaire un collègue a fait un truc un peu crade. Il démarre le thread et attend au maximum un timeout donné. Si le thread n'est pas terminé a la fin du timeout, l'action est considérée comme échouée et l'appli continue (le thread termine dans les limbes, s'il finit un jour c'est bien, sinon il reste zombie .. berk berk)

Bulbo