Fonction lente : Arrêter puis relancer.

Version imprimable

Voir 40 message(s) de cette discussion en une page

14/01/2012, 20h55
thelvin

Citation:

Envoyé par Djakisback

mais la dépréciation de méthodes comme stop() m'ennuie car on assiste de plus en plus le développeur...

Idéalement, stop() ne devrait pas être dépréciée, mais supprimée. Ce n'est pas le cas, pour rétrocompatibilité.
Remplacer par interrupt() est toujours possible. On pourrait me dire qu'interrupt() est plus difficile, mais :
- Infiniment moins que de comprendre dans quels cas stop() pourrait être utilisé sans risque. Donc non.
- Je croyais que c'était mal d'assister le développeur ?
14/01/2012, 21h04
JoeChip

Citation:

on assiste de plus en plus le développeur

Ouais, c'est mal, faudrait tout faire en ASM, comme ça le développeur ne serait pas assisté... :mrgreen:
15/01/2012, 03h47
Djakisback

Vous êtes taquins ;)
Pour étayer ma pensée, j'aime bien avoir la possibilité de faire planter ma machine, ce qui devient de moins en moins possible avec Java. Sinon quand je parle d'assistanat ce n'est pas de l'élitisme mais juste une question de liberté dans le sens "avoir la main". Par exemple pour moi, un System.gc() devrait libérer la mémoire et non pas "suggérer" de libérer la mémoire. En ASM au moins, tu sais ce que tu fais :)
15/01/2012, 04h58
thelvin

Ah bah oui mais ça c'est pas neuf, l'un des objectifs de Java c'est l'exact contraire.

Si ça te plaît pas, on peut encore le comprendre, mais c'est pas les technologies qui manquent. Prends-en une autre.
Et si tu penses que tout le monde devrait toujours vouloir qu'on puisse facilement planter la machine et gérer la mémoire soi-même au risque donc de la bousiller... Ce qui donc voudrait dire qu'un langage ne peut pas se fixer l'objectif d'empêcher ça et que pour cette raison Java ne devrait pas exister en tant que tel... Si tu penses ça, donc, je ne peux rien pour toi. Tu n'as pas encore assez essayé de comprendre ce qu'on peut faire et ne peut pas faire en fonction de ce qu'on a et n'a pas.
15/01/2012, 07h22
Djakisback

Hmm, ça dérive complet HS mais je trouve tes propos un peu durs et je peux pas m'empêcher de répondre :)
Je tape du Java depuis longtemps, par obligation, mais j'adore ce langage. Mon souhait, depuis le début (c'est pas trop neuf effectivement ;) ), serait qu'il évolue vers une plus grande souplesse pour l'utilisateur, notamment dans la gestion de la ram, sans passer par les classes proposées.
Après, je ne t'ai jamais demandé de faire quelque chose pour moi, mais je vais le faire : si tu as un code dans un langage quelconque pour bousiller la ram ça m'intéresse :D
15/01/2012, 09h56
JoeChip

Le progrès, en programmation "haut niveau", c'est justement de pouvoir ne pas se soucier des détails "bas niveau". L'idéal étant : si ça compile, c'est qu'il n'y a pas de bug. L'opposition entre "je veux faire ce que je veux, quitte à planter l'OS", et "je ne veux pas m'embêter avec des obscures erreurs de pointeurs" date déjà de quelques décennies (genre C vs Borland Pascal).

Pour moi il est évident que l'approche "si ça compile ça marche" est beaucoup plus rapide que "je veux pouvoir optimiser au quart de poil", qui fait que les programmeurs passent un temps fou à accélérer des trucs absurdes, genre que ça prenne 0.05 seconde au lieu de 0.2 secondes pour exploiter une entrée utilisateur.

Après, même en Java, si on veut perdre du temps à faire planter la machine, ya une lib "unsafe", hein.
15/01/2012, 13h01
haskouse

Est ce qu'on peut revenir au sujet principal de ce post ? :mrgreen:
15/01/2012, 14h58
thelvin

Citation:

Envoyé par haskouse

Est ce qu'on peut revenir au sujet principal de ce post ? :mrgreen:

Je ne me serais pas permis de dériver comme ça s'il y avait encore quelque chose à en dire.
Tu as des choses à ajouter ?

Bon j'ai utilisé le "Interrupt" au lieu du "Stop", ça donne un truc de ce genre :
Dans le ThreadCalculator :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
@Override
    public void run() {
        try {
            this.resultat = ClasseMetier.facto(this.parametre);
 
            Thread.sleep(1);
        } catch (InterruptedException e) {
            this.continuer = false;
        } finally {
            this.continuer = false;
        }
 
    }

Puis dans la classe de Test :

Code:

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
ThreadTimer tt = new ThreadTimer();
        ThreadCalculator tc = new ThreadCalculator();
 
        int param = 100000000;
        int timeout = 2;
 
        tt.setNbrSecondes(timeout);
        tt.start();
 
        System.out.println("Test avec param = " + param);
        tc.setParametre(param);
        tc.start();
 
        do {
            while (tt.isContinuer() && tc.isContinuer()) {
            }
 
            if (!tc.isContinuer()) {
                tt.setContinuer(false);
                System.out.println("calcul terminé");
 
                System.out.println("Facto(" + tc.getParametre() + ") = "
                        + tc.getResultat());
                break;
            }
 
            if (!tt.isContinuer() && tc.isContinuer()) {
 
                System.out.println("temps écoulé");
 
                tt.setContinuer(false);
                tt = new ThreadTimer();
                tt.setNbrSecondes(timeout);
                tt.setContinuer(true);
                tt.start();
 
                param -= 10000000;
                tc.interrupt();
                tc = new ThreadCalculator();
                System.out.println("Test avec param = " + param);
                tc.setParametre(param);
                tc.start();
            }
 
        } while (tc.isContinuer());

Des remarques ?

16/01/2012, 10h37
tchize_

Le sleep ne sert à rien. Si la méthode ne lance pas d'InterrupedException d'elle même, le try catch ne sert à rien.
Ta méthode avec le do/while va manger tout le cpu à juste vérifier des flag. Met cette logique dans l'action de ton timer.

Voir 40 message(s) de cette discussion en une page