Discussion :

[nouknouk]

Bonjour à tous,

une petite question de (gros) débutant en Java : voilà, je me demandais quand est-ce que l'EDT était lancé et s'il l'était systématiquement pour toute nouvelle application

Le contexte:
Pour mieux situer mes questions, je précise que je suis un développeur confirmé en C++ avec Qt. Je me mets doucement au Java et je cherche a faire un parallèle entre la boucle d'événements gérée par l'event loop de Qt et l'EDT dans Java (si parallèle il y a).

Le cas pratique :
Plus précisément : je susi en train de développer une classe FrameSocket, capable de communiquer en TCP avec une autre FrameSocket en envoyant et recevant des 'frames' ( <=> des paquets de données avec un format perso prédéfini).

Chaque instance de ma tite classe lance donc son propre thread pour attendre, lire les données les données reçues et en extraire la substantielle moelle (entendez par là désérialiser mes types de données perso).

Ce que je voudrais maintenant implémenter c'est un mécanisme d'event + listeners qui va émettre un event lorsque :
- la connection a été perdue
- une nouvelle frame a été reçue et désérialisée.

Après quelques lectures (merci aux tutos de ce site !) je pense que poster les événements dans l'EDT est le meilleur moyen pour arriver à mes fins puisque logiquement, dans le cas d'une appli avec UI ces événements (ainsi que ceux générés par l'UI) seront à l'origine des changements de mon modèle et de l'UI elle même.

La question :
La question que je me pose : est-ce que l'EDT est un thread ... euhm ... disons ... "principal" ... qui est systématiquement lancé à chaque démarrage d'application et d'applet, même lorsqu'une l'application n'utilise pas d'UI ?
(en d'autres termes, le jour où je réutiliserai ma FrameSocket dans une autre appli, serai-je sûr que je peux compter sur la présence de l'EDT ?)

Question subsidiaire (si la première réponse est affirmative): si une application n'utilise pas d'UI, mais qu'elle a un fonctionnement événementiel, un développeur java utilisera-t-il systématiquement l'EDT pour gérer ses événements ? (avec invokeLAter, invokeAndWait, ...)
Typiquement, mon serveur avec 15 clients connectés aura 15 FrameSockets instanciées (donc 15 threads) et le modèle + controller sera géré par l'EDT ?
Y a-t-il d'autres façon de faire avec leurs avantages (sans réinventer la roue inutilement) ?

Dernière question (pour la route, et si je vous ai pas encore assez ennuyé avec mes questions bêtes) : Avec Qt par exemple, le thread principal qui gère l'event loop est simplement le thread principal de l'appli. On a quelque chose dans le genre:

Code :

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

1
2
3
4
5
6
 
int main(int argc, char** argv) {
  QApplication appli(argc,argv);
  appli.setMAinWindow(new MaWindow());
  return appli.exec();
}

Pourquoi il a été décidé en Java que le thread de l'EDT ne soit pas le même que le thread du main() ?



Merci beaucoup d'avance pour vos précisions.

[jproto]

Pour ta gestion d'événement, je te conseille http://rom.developpez.com/java-listeners/.

Pour ce qui est de l'EDT, il est géré par la couche AWT. Il n'y a à mon sens aucune raison qu'il soit lancé dans une application sans IU.

Je ne trouve donc pas opportun d'implémenter ta classe en exploitant des fonctions qui lui sont propres (invokeLAter, invokeAndWait ... d'ailleurs, il me semble que ces fonctions sont fournies par swing et non AWT).

Chris.

[nouknouk]

salut,

tou d'abord, merci pour tes réponses.

- Concernant la notion d'observer, je connais bien le pattern et j'ai déjà lu le tuto que tu me proposes.

- Concernant mon cas de figure, il est un peu particulier. Prenons le cas du serveur acceptant plusieurs connections, donc contient plusieurs instances de Socket qui peuvent recevoir à tout moment de nouvelles données à traiter.

-> si j'ai 15 sockets, je ne peux pas me permettre de n'avoir qu'un seul thread bloqué par un socket.getInputStream().read() car je n'écouterais qu'un seul socket et pas les 14 autres.

-> pour des raisons de performances, je ne peux pas non plus dire "je vais régulièrement itérer sur chacune des sockets et faire un socket.getInputStream().isAvailable() pour voir si j'ai quelque chose à lire". Ce serait de l'attente active et cela boufferait inutilement des ressources procs de mon serveur.

=> La seule solution qui me semble viable est d'instancier un thread dédié à chaque socket (appelons-les les "socket's threads"). Chacun d'eux fait un socket.getInputStream().read() et donc est endormi tant qu'il n'y a rien de nouveau à lire. Lorsque quelque chose arrive sur sa socket, il se réveille et récupère lesdites données.

Le problème avec cette solution est qu'une fois que le thread de mon socket a récupéré les données d'une frame, il va avertir un listener pour effectuer le traitement approprié sur l'unique modèle de données du serveur. Ce modèle est commun à toutes les connexions.

Souci: quel thread doit déclencher et effectuer l'action du listener ? Pour éviter un accès concurrent à mon modèle par plusieurs "socket's threads" en même temps, je ne peux pas faire effectuer l'action par le "socket's thread" lui même.
Donc je me dis qu'il me faudrait un unique thread supplémentaire (appelons le "action thread") qui, lui, sera le seul à toucher aux données du modèle. les "socket threads" n'auront qu'à lui poster des événements quand il y a quelque chose à faire (d'ou les événements 'frame reçue'). Ainsi, je garantis l'absence de d'accès concurrent à mon modèle puisque chaque action sera exécutée séquentiellement.


D'où l'idée d'utiliser l'EDT comme "action thread" puisque:

- il implémente déjà la notion d'événements, d'event loop, de queue thread safe, etc... et les devs du SDK java ayant plus d'expé que moi, je leur fais plus confiance

- AWT & Swing font partie du framework de base de java ( >= 1.2 si mes souvenirs sont bons). Donc ma classe serait réutilisable quel que soit la nouvelle application dans laquelle je voudrais l'utiliser.

- l'EDT n'a pas nécessairement besoin d'une UI pour marcher, cf. ce code de test :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import javax.swing.SwingUtilities;
 
public class EdtTest {
	public static void main(String[] args) {
		System.out.println("avant l'EDT");
		SwingUtilities.invokeLater( new Runnable() {
			public void run() {
				System.out.println("dans l'EDT");
			}
		});
	}
}
// l'EDT est bien créé et effectue bien mon action
// alors qu'aucune partie du framework pour l'UI n'a été utilisé.

Vala vala ... j'ai tout faux docteur ?


EDIT: ps: j'ai trouvé la réponse à ma première question : après quelques tests simples, il apparaît que l'EDT est créé de façon transparente la première fois qu'on a besoin de lui (instanciation d'une JFrame, 1er appel d'invokeLAter(), ...). Reste la question de savoir si ma démarche est globalement acceptable ou si c'est une hérésie totale .

[adiGuba]

Salut,

Reste la question de savoir si ma démarche est globalement acceptable ou si c'est une hérésie totale .

Pour moi c'est un peut idiot d'utiliser l'EDT pour cela...

Si tu utilises Java 5.0 tu peux utiliser le package java.util.concurrent qui te permettra de faire tout cela (et même plus de manière assez simple). Tu peux par exemple utiliser une BlockingQueue pour "passer" des données de tes "socket thread" vers ton "model thread"...


Sinon tu peux utiliser des Collections synchronisé pour cela.

a++

[nouknouk]

Si tu utilises Java 5.0 tu peux utiliser le package java.util.concurrent qui te permettra de faire tout cela (et même plus de manière assez simple).

Ok, merci beaucoup pour l'info. J'avais pas encore vu ce package
Je vais voir ce que je peux en retirer.

Pour moi c'est un peut idiot d'utiliser l'EDT pour cela...

Pourrais-tu préciser pourquoi exactement ? (EDT = usine à gaz ; pas 'conventionnel' ; ...).
-> Perso, je me disais bêtement que dans le cas où ma class FrameSocket est utilisée dans une appli avec UI, ça permettrait justement de ne pas avoir un thread supplémentaire puisque l'EDT sera de toute façon nécessaire à l'UI...
-> De plus, dans le cas de mon futur client qui utilisera ma FrameSocket, c'est la réception de frames qui sera à l'origine de presque tous les changements d'UI (update de la user list, ...)

Plus globalement, quand un dev Java a besoin de gérer des événements (non graphiques) dans une appli, comment fait-il ?

[Baptiste Wicht]

Plus globalement, quand un dev Java a besoin de gérer des événements (non graphiques) dans une appli, comment fait-il ?

Il utilise le gestionnaire d'événements

C'est très simple à faire, tu as un objet écouté qui posséde des écouteurs et dès qu'il le faut il avertit les écouteurs qui réagissent ensuite comme il le faut...

[adiGuba]

Pourrais-tu préciser pourquoi exactement ? (EDT = usine à gaz ; pas 'conventionnel' ; ...).

L'EDT doit servir uniquement à mettre à jour l'affichage.

Si tu n'as pas de GUI, c'est bête de charger les différents composants graphiques pour simplement mettre à jour un modèle de données...

Et si tu as une GUI, tu risque d'avoir des ralentissement à cause des traitements de gestion que tu ferais dans ton EDT.

Plus globalement, quand un dev Java a besoin de gérer des événements (non graphiques) dans une appli, comment fait-il ?

Il y a plusieurs moyens de faire : il faudrait avant tout connaitre tes besoins (quels évènements sont lancés, par qui, qui doit les traiter, comment, etc.)


a++

[nouknouk]

C'est très simple à faire, tu as un objet écouté qui posséde des écouteurs et dès qu'il le faut il avertit les écouteurs qui réagissent ensuite comme il le faut...

Oui, c'est la définition du pattern observer. La question n'est pas dans son implémentation, mais à savoir quel thread doit s'occuper du traitement initié par l'événement.

Il y a plusieurs moyens de faire : il faudrait avant tout connaitre tes besoins (quels évènements sont lancés, par qui, qui doit les traiter, comment, etc.)

Ici, le sujet est la classe FrameSocket, qui s'exécute donc dans son ptit thread perso. L'observer est la partie tierce de mon appli, donc le controlleur qui gère mon modèle et éventuellement l'update d'UI.

Le souci : si j'implémente bêtement le pattern observer, c'est le "socket thread" (le sujet) qui va faire un appel de la callback de mon traitement défini dans mon listener. Donc c'est le "socket thread" qui va effectuer le traitement attaché (accès r/w au modèle ; update d'UI ; éventuellement d'autres choses en cascade). D'où deux problèmes majeurs :

1/ je risque des accès concurrents à mon modèle puisque j'ai de multiples "socket thread", ou alors je vais devoir gérer la concurrence sur tout mon modèle.

2/ pour chaque listener, je vais devoir gérer différents cas (thread courant == socket thread ; thread courant == EDT thread ; thread courrant == autre thread) et adapter le traitement en conséquence (modif des données ; update d'UI, ...)

Tout ça est bien entendu faisable mais me paraît très lourd en quantité de code puisque chaque callback devra gérer les différents cas. D'ou l'idée de dire qu'il n'y a qu'un seul thread qui va traiter les événements, l'EDT ; quand je poste un événement celui ci sera systématiquement traité par l'EDT et personne d'autre, que l'événement provienne d'une action de l'utilisateur, d'une socket ou de quoi que ce soit d'autre.

En espérant avoir été un peu plus clair ...

1- Si tu n'as pas de GUI, c'est bête de charger les différents composants graphiques pour simplement mettre à jour un modèle de données...
2- Et si tu as une GUI, tu risque d'avoir des ralentissement à cause des traitements de gestion que tu ferais dans ton EDT.

1- Exact. Tous les composants graphiques sont-ils chargés, même si je n'utilise que l'EDT et pas le reste ? cela représente quelque chose de vraiment lourd (mémoire ? autres ressources ?)

2- Uniquement si mes traitements associés sont lourds. Ce ne sera vraisemblablement pas mon cas dans l'immédiat. S'il s'avérait par la suite que j'ai des traitements réellements lourds à faire à la réception d'un tel événement, rien ne m'empêchera de les démarrer dans un thread séparé comme n'importe quel autre traitement lourd, non ?

[adiGuba]

D'ou l'idée de dire qu'il n'y a qu'un seul thread qui va traiter les événements, l'EDT ; quand je poste un événement celui ci sera systématiquement traité par l'EDT et personne d'autre, que l'événement provienne d'une action de l'utilisateur, d'une socket ou de quoi que ce soit d'autre.

Un seul thread devra traiter les événements : OK !
Mais pourquoi l'EDT ???? Son objectif est de traiter les évènements graphiques et l'affichage. Pourquoi l'encombrer encore avec d'autres traitements qui pourraient poser des problèmes d'affichage ?

Pourquoi ne pas utiliser un thread spécifique c'est bien plus simple...


Tu as (au moins) deux possibilités assez simple, utiliser une BlockingQueue pour passer les données (les deux exemples utilise le design pattern Singleton) :

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class ModelThreadQueue {
	private final static ModelThreadQueue instance = new ModelThreadQueue();
	private BlockingQueue<Data> queue = new LinkedBlockingQueue<Data>();
	// Thread principale qui s'occupera de traiter les données
	private final Thread thread;
 
	// Constructeur privée (pour éviter les doublons)
	private ModelThreadQueue() {
		// On lance le thread de traitement des données
		this.thread = new Thread("ModelThread") {
			@Override
			public void run() {
				takeData();
			}
		};
		this.thread.start();
	}
 
	// Accesseur public (voir DP du Singleton)
	public static ModelThreadQueue getInstance() {
		return instance;
	}
 
 
	private void takeData() {
		try {				
			while (true) {
				// Traitement des données de data
				callbackFonction( queue.take() );
			}
		} catch (InterruptedException e) {
			// Interruption : fin du thread
			e.printStackTrace();
		}
	}
 
	public void callback(Data data) {
		// On ajoute les données dans la queue,
		// elle seront traité dès que possible par 
		this.queue.offer(data);
	}
 
	private void callbackFonction(Data data) {
		// Traitement des données
		// (méthode appelé en interne)
	}
 
}

Soit Data les données passées à la méthode callback(). Lorsqu'elle est appelé, l'objet est ajouté dans une queue FIFO (et thread-safe bien sûr) et la méthode retourne immédiatement. Le thread (lancé dans le constructeur) récupèrera les données de la queue afin de les traiter au fur et à mesure.

Dans tes SocketThread, il suffira de faire quelque chose du style :

Code :

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

ModelThreadQueue.getInstance().callback( data );

Seconde solution, tu peux utiliser un Executor afin de passer directement des objets Runnable et ainsi avoir un fonctionnement "proche" de celui de l'EDT...

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
31
class ModelThreadExecutor {
	private final static ModelThreadExecutor instance = new ModelThreadExecutor();
	private Executor executor = Executors.newSingleThreadExecutor();
 
	// Constructeur privée (pour éviter les doublons)
	private ModelThreadExecutor() {
	}
 
	// Accesseur public (voir DP du Singleton)
	public static ModelThreadExecutor getInstance() {
		return instance;
	}
 
	public void invokeLater(Runnable r) {
		executor.execute(r);
	}
 
	public void callback(final Data data) {
		invokeLater(new Runnable() {
			public void run() {
				// Traitement des données :
				callbackFonction(data);
			}
		});
	}
 
	private void callbackFonction(Data data) {
		// Traitement des données
		// (méthode appelé en interne)
	}
}

Ici on utilise un executor qui utilise un thread unique afin de garantir l'unicité de l'accès aux données (et qui est automatiquement recrée s'il "meurt"), et la méthode invokeLater() permet de lui passer des traitements (comme le montre l'exemple avec la méthode callback() ).



Et il y a encore plusieurs autres manières de faire sans monopoliser l'EDT...


a++

[nouknouk]

Ok, merci pour ton exemple. Je vais regarder ça.

En résumé, on a trois solutions :


La solution 1 (la mienne) sépare bien les listeners des sujets entre socket et controlleur pour éviter les accès concurrents (modèle & controlleur), mais pourrait risquer de ralentir l'affichage (dans mon cas, les callbacks étant de l'ordre de 1 à 2 par seconde, c pas critique). Autre avantage: controlleur & UI étant dans le même thread, le code d'update d'UI est "immédiat" (pas d'invokeLater() ou assimilé).

La solution 2 (implémentation de l'observer toute bête) n'est clairement pas acceptable car elle impose de gérer la concurrence dans tous les callbacks du controlleur. Cela imposerait un surplus de code non négligeable.

La solution 3 (la tienne) sépare encore plus TOUS les listeners de TOUS les sujets. Aucun risque de ralentir l'affichage ; moins gourmand en ressources si appli sans UI. L'inconvénient : à chaque fois que le controlleur voudra updater l'UI, il faudra passer par un 'invokeLater()' ou assimilé car controlleur & ui sont dans deux threads séparés ; idem pour les actions de l'ui vers le controlleur.

Merci encore :-)

EDIT: je vois un autre désavantage à ta solution (ie #3) : cela m'imposera d'implémenter un mapping de tous les listeners & events de Swing vers mon event loop perso (en plus de celle indispensable pour la comm " sockets <=> controleurs"), non ?

[sinok]

Attention le fait de ne jamais utiliser invokeLater est en général un mauvais signe.

Celà veut dire que tu fais dans l'EDt des traitements qui peuvent bloquer ton IG, ce qui extrèment mauvais.

Donc pour moi ta solution n'est pas franchement bonne non plus

Donc je vote Adiguba sur ce plan

[nouknouk]

Attention le fait de ne jamais utiliser invokeLater est en général un mauvais signe.
Celà veut dire que tu fais dans l'EDt des traitements qui peuvent bloquer ton IG, ce qui extrèment mauvais.

salut,

amha, tout dépend du traitement proprement dit :

- si le traitement en question consiste à extraire d'un byte array une string de quelques dizaines de caractères et ensuite l'afficher dans un composant graphique de l'UI, cela ne gênera en rien sa réactivité (Au contraire, je pense qu'un traitement aussi simple sera moins coûteux en temps que l'instanciation et le démarrage d'un nouveau thread). Après, il faut également prendre en compte le nombre d'événements tels que ceux-ci que tu auras à gérer par seconde pour estimer la charge globale. Dans mon cas, comme précisé ci-dessus, la charge sera minime.

- si le traitement est bien plus lourd (calculer le hash d'un fichier de 500Mo par exemple), il est évident que ce genre de traitement prendra beaucoup plus de temps et devra donc être exécuté dans un thread séparé (par exemple en utilisant une instance de SwingWorker), sous peine d'avoir un freeze de l'interface.

A titre d'exemple, je travaille sur un IDE en C++ / Qt. Dans Qt, les sockets sont gérés dans le même thread que celui qui gère la boucle d'événements (y compris ceux pour l'UI). Et je n'ai jamais eu à déplorer un quelconque ralentissement de mon UI. En effet, tous les traitements lourds (comme lancer la compilation d'un fichier) sont gérés de façon asynchrone dans un thread (process) séparé.