Bonjour
 
j'ai un probleme d'occupation cpu pour une application
réseau. cette derniere crée un thread qui boucle
à l'infini pour envoyer des messages qu'on lui donne...
le probleme est que cette boucle entraine une utilisation
maximale des ressources cpu, alors qu'on aimerait avoir un
comportement plus proche d'un daemon, ou encore d'un  
procédé de callback comme pour les i/o...
y-a-t-il une solution, spécifique java ou non ?

Un bout de code?????

Dans ton Thread, il faut absolument qu'à un moment donné tu fasses :  
 
Thread monThread;
...
monThread.sleep(leTempsQueJeVeux);
 
où leTempsQueJeVeux est un entier en millisecondes (à vérifier pour l'unité).

voila en gros ce que fait le run() du thread:
 
while(m_stop == false)
{
 if (m_answer.isEmpty() == false)
 {
  synchronized(m_parentJob)
  {
   String ans = (String)m_answer.firstElement();
   System.out.println("Answer manager " + m_id + " > " + ans);
   outToClient.print(ans);
   m_answer.remove(ans);
  }
 }
}
 
m_answer est un vecteur, et outToClient... enfin c assez explicite  

rajoute un Thread.yield() dans ta boucle : ca rend la main au système.
c'est indispensable.
 
Le thread.sleep() fonctionne aussi mais endoer ton thread pdt le temps que tu as définie, ce qui n'est pas forcément ce que tu souhaites.

D'un autre côté, utiliser un Thread pour ça, ça me paraît douteux : utiliser un thread pour écouter une socket, d'accord, mais après...8|....je te suis pas!
 
Il sert à quoi, exactement, ton vecteur???

Tu pourrais peut-etre aussi gagner en bufferisant l'affichage plutot qu'effectuer un "System.out.println"(je crois que cette fonction ne rend pas la main au thread principal tant qu'elle n'a pas finit)
Tu devrais gagner en fluidite.

Voila une solution qui fonctionne très bien chez moi.
 
D'une part tu as ton thread qui contient un vecteur v
 

 
et d'autre part tu as une méthode pour ajouter des messages
 

 
and it works perfectly baby
 
Dis moi si ca t'aide ...

je persiste : si tu ne souhaite pas bloquer ton thread, fais un yield !
 

 
tu risques d'avoir des probs de deadlock là. En fait tout dépend des requierments du systeme. Avec ma solution par exemple, il fait un test toutes les deux sec en inactivités ce qui n'est pas méchant.
 
Et il y a un notify qui enclence une InterruptedException dès que tu ajoutes un message donc c'est relativement correct.  
 
Maintenant faut pas utiliser ton thread pour autre chose que ca

ok merci, je vais voir tout ca...
pour ce qui est du thread, c'est la seule solution que j'ai
trouvé, sachant que le thread parent gere la connection principale (d'ou le synchronized, histoire de ne pas send n'importe quand)... le pb c'est que je suis obligé de faire un appelle bloquant sur l'ecoute du client pour pouvoir detecter sa deconnection (et donc killer le process), mais en mm temps, il faut je puisse envoyer a cette mm connection des messages quand ils arrivent... voila le pourquoi du comment, j'espere que c'etait clair

 
pas du tout. SI tu veux voir si la connec est bonne tu peux implémenter un protocole très simple, le ping pong. Ton servoir envoie un ping et si après un temps donné tu ne recois pas de pong tu considère que ton clien est down.

pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec.
ou bien y a un truc qui m'échappe ...

benou a écrit a écrit :   pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec. ou bien y a un truc qui m'échappe ...

 
 
bin tu yeld donc il faut bien que on te réveille non? si le notify se crashe chze moi, le thread se réveillera de toutes façons au bout de 2 sec
 
si je faisais this.wait();
 
ce serait pareil que ta solution

nan yield ca rend le main, mais ca arrête pas le thread ...
ca laisse juste les autres thread s'excuter.
ex :  
 
While (true) {
   Thread.yield();
}
 
ca ce ne sera pas bloquant : les autres thread fonctionneront encore !
D'ailleur, je pense qu'avant de se mettre en pause, le sleep() appelle le yield()

Mais pourquoi tu veux pas écrire et écouter en même temps sur ta socket??? 8[  
Pasque sinon, le bout de mon client qui marche nickel (c'est un bout du client du nouveau chat Orange!! (à voir là : chat.orange.fr)
 
 
Le début :  
 
    public Client(String ip, int port) throws IOException {
        socket = new Socket(ip, port);
        reader = new BufferedReader(new InputStreamReader(server.getInputStream()));
        writer = new PrintWriter(new OutputStreamWriter(server.getOutputStream()), true);
        thread = new Thread(this);
        thread.setPriority(Thread.NORM_PRIORITY);
        thread.start();
    }
 
la méthode run()
 
    public void run() {
        String line;
        while (thread != null) {
            try {
                if ((line = reader.readLine()) != null) {
                   try {  
                      Message msg = MessageFactory.getMessage(line);
                      msg.anwser(parent);
                   } catch (MessageFormatException mfe) {
                   // gestion...
                   }
                } else {
                    fireEvent(NetworkEvent.SERVERDIED);
                }
            } catch (IOException ioe) {
                fireEvent(NetworkEvent.SERVERDIED);
            }
              thread.yield();
        }  
 
Et la méthode send :  
 
    public void send(String msg) {
        writer.println(msg);
        writer.flush();
    }
    }
 
 
 
Côté serveur, c'est un peu plus complexe :  
 
l'objet ServerSocket instancie un objet Runnable pour gérer la Thread, mais le run et le send sont similaires à ceux là....
 
Effectivement, y'a un yield, là dedans!!

gfive a écrit a écrit : Effectivement, y'a un yield, là dedans!!

victoire !!

damn!
 
benou        
 

 
bien vu  

Ouais, mais ça fait un an que je l'ai codé, ce bout là!!

darklord22 a écrit a écrit : damn!benou

mdr !

t'as bossé pour orange?

On a installé mardi, entre 2h et 7h!!
Et là, première rafale de corrections à faire!!
 
Mais je bosse pas chez Orange, je bosse dans une p'tite boite qui bosse pour orange.

gfive > le pb c'est que le client envoye des messages (on attend avec un receive donc bloquant) et on lui renvoie un aquittement, et on rempile sur le receive.... a coté de ca, on peut avoir a tt moment a lui envoyer des messages... avec un seul thread, on serait obligé d'attendre de recevoir un msg pour pourvoir renvoyer le notre apres aquittement... d'ou un second thread avec section critique

Ah ouais...J'ai fait autrement, pour l'acquitement, moi....: comme j'en attend pas toujours, j'ai un système d'objects qui attendent : quand j'envoie un message pour lequel je dois attendre une réponse, je met mon objet qui attend dans une HashMap, indexé par l'Id du message....Quand un acquitement est reçu, je lis l'ID, et si un objet attend cet Id là, j'appelle la méthode à appeller quand l'Id est reçu....

oui... mais la voila, j'ai pas la main sur le protocole client, faut donc faire avek !  

shit!!

darklord22 a écrit a écrit : damn!   benou             bien vu

 
Alors, qui c'est le plus fort ?
 
Solution : Facile, c'est Bill Gates. En anglais on dit qu'il a une "fucking policy". Une politique enculante, quoi !

Cherrytree a écrit a écrit :   Alors, qui c'est le plus fort ?

nananan ... ose pas me comparer à dark : il maîtrise bien plus de domaine que moi en Java !!

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!!

gfive a écrit a écrit : En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!!

Ah ! Qui sait, si ça se trouve il déteste programmer en Visual C++. Si ça se trouve, il déteste programmer