Thread et InterfaceRésolu

Question

Bonsoir a tous,
voila en fait je suis en train de plancher sur un problème de conception auquel je n'arrive pas à trouver de solution. Voila en fait je développe une application qui a une interface principale et j'aimerais que cette interface lance une deuxieme interface mais en parallèle pour que lorsqu'une des deux interfaces soit bloqués cela ne bloque pas l'autre.

Donc en fait voila comment je procéde: en fait mon interface lance un thread et dans ce thread je lance mon interface, voila le code:
public class JControler extends Thread
{
    public void run()
    {  this.productDlg = new JDlgProducteur(); /* reste de la classe control les actions sur les differents composant de la fenetre*/}
}

le probleme c'est que ca me lance l'interface mais le thread se termine et donc en fait je me retrouve avec un thread unique. donc si un des deux dialog bloques, alors ca bloque toute mon application.
et en fait je ne vois pas trop comment résoudre ce problème...

donc voila si quelqu'un pouvait me conseiller sur la méthode à suivre pour lancer deux interfaces dans deux interfaces thread distinct...

Ou peut etre que la solution serait de déclarer mon interface comme ceci:
class Dlg extends JFrame implements Runable
{ [...] public void run() { ... } [...] }

et que la mon interface va se lancer dans un thread appart. mais ma gestion des evenement de la fenetre se trouvant dans la classe qui lance le thread, va continuer de faire partie du thread principale.

donc en fait je ne sais pas trop comment faire, pourriez-vous m'éclairer svp?
Bob...
"Vaut mieux se taire et passer pour un con, que de l'ouvrir et ne laisser aucun doute sur le sujet..."

cs_AlexN · Accepted Answer

Salut,

Swing et le multi-threading. Deux articles qui permettent de mieux comprendre ce sujet :

- Threads et performance avec Swing
- SwingWorker (Java SE 6)

Swing est un sous système de threads de la jvm. Ce sous système n'est pas thread safe, sauf pour quelques methodes : repaint(), invalidate() et revalidate() -c'est à dire que la communication avec swing (l'invocation des méthodes swing) par des threads externes (ceux de la jvm) doit respecter un "contrat de communication" (une gestion des evenements centralisée par un seul thread qui est l'EDT). Le contrat est que toute communication avec l'interface doit se faire à travers les methodes invokeLater ou invokeAndWait de SwingUtilities. Ces méthodes sont chargées de créer un thread par message/evenement puis de placer ces threads dans la file d'attente de l'EDT, sans bloquer le thread qui les utilise (invokeLater) ou en mode bloquant (InvokeAndWait). Tout thread qui ne respecte pas ce contrat peut bloquer le système swing ou en etre exclu comme dans ton premier cas ou le thread JControler est créé dans un contexte externe à l'application swing (le thread de ton JControler, qu'il soit une extension de Thread ou une implémentation de Runnable, est créé dans la jvm et pas dans le sous système swing, parce qu'il n'est pas englobé dans un appel de type InvokeLater).

Une application swing est composé de trois threads :

- le main application thread qui execute le main()
- le toolkit thread qui est chargé de faire l'interface evenementielle (clic souris, clavier...) entre swing et l'os. Il envoi tous les messages à l'EDT :
- l'event dispatcher thread ou EDT qui est le coeur de swing. Il a la responsabilité de la gestion de la file d'attente des evenements swing et la distribution de ces evenements à chaque composant

Tout thread externe souhaitant communiquer avec le système swing doit passer par l'EDT.

D'un autre côté, il est tout à fait possible d'envisager une application swing dont certains threads lancés depuis l'interface deviennent indépendants de l'EDT, parce ces threads réalisant des opérations lourdes pourraient bloquer l'EDT. Seulement, lorsque ces threads devenus indépendants veulent communiquer avec l'interface, il doivent à nouveau respecter le contrat (passer par l'EDT). Comme ils sont désynchronisés de l'EDT, ils doivent utiliser les methodes invokeLater ou invokeAndWait de SwingUtilities pour communiquer à nouveau avec lui (placer des messages dans sa file d'attente). Un mécanisme un peu plus perfectionné est celui des SwingWorker.

Faire une interface pour controler un seul thread ne me semble pas la meilleure solution (surtout si le programme principal est amené à lancer 50 threads, ca fait 50 interfaces...). Une seule interface pour controler plusieurs threads, du moment qu'ils respectent le contrat swing, est plus dans l'esprit de swing.

cs_LordBob · Answer

ok merci pour toute ces informations. j'entrevoie le coeur du problème et peut-être une ou deux solutions.
je vais donc étudier tout cela pour trouver une solution à mon problème.
merci beaucoup pour tes informations en tout cas.
Bob...
"Vaut mieux se taire et passer pour un con, que de l'ouvrir et ne laisser aucun doute sur le sujet..."

Thread et Interface

2 réponses

Votre réponse

Discussions similaires