J'ai une application qui gère des espèces de plugin.
Certains doivent pouvoir travailler indépendemment, d'autres pas
forcément; mais tous génère un événement qui permet à mon application de
réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un
événement particulier sur une autre classe. Et quand il doit réagir, il
génère lui-même l'événement qui sera intercepté par l'application
principale.
Est-il correct de faire comme ceci dans la méthode run() ? :
public class plugin extends Runnable{
public void run(){
while(! _isfinished){
// y a rien a faire donc on rends la main au processeur
Thread.yield();
}
}
// ici on réagit à l'événement généré par quelque chose
public void evenement(Event evt){
// on déclenche l'événement plugin qui sera reçut par
// l'aplication principale
triggerPluginEvent(evt);
}
}
Si mon application n'est pas graphique, peut-on générer des événements
dans des classes qui ne sont pas des threads indépendants, mais
instanciés dans le thread principal (celui de l'application )
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Kupee
Christophe M. wrote:
J'ai une application qui gère des espèces de plugin. Certains doivent pouvoir travailler indépendemment, d'autres pas forcément; mais tous génère un événement qui permet à mon application de réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un événement particulier sur une autre classe. Et quand il doit réagir, il génère lui-même l'événement qui sera intercepté par l'application principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus adaptées, en effet, avec le yield() ton thread peut se réveiller a n'importe quel moment ce qui n'est pas nécéssaire apparament. En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu fais un notify (le wait et le notify doivent etre dans des blocs synchronized avec un lock sur le meme objet afin que le notify réveille bien ton (ou tes) thread(s)
Si mon application n'est pas graphique, peut-on générer des événements dans des classes qui ne sont pas des threads indépendants, mais instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
Christophe M. wrote:
J'ai une application qui gère des espèces de plugin.
Certains doivent pouvoir travailler indépendemment, d'autres pas
forcément; mais tous génère un événement qui permet à mon application de
réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un
événement particulier sur une autre classe. Et quand il doit réagir, il
génère lui-même l'événement qui sera intercepté par l'application
principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus
adaptées, en effet, avec le yield() ton thread peut se réveiller a
n'importe quel moment ce qui n'est pas nécéssaire apparament.
En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu
fais un notify (le wait et le notify doivent etre dans des blocs
synchronized avec un lock sur le meme objet afin que le notify réveille
bien ton (ou tes) thread(s)
Si mon application n'est pas graphique, peut-on générer des événements
dans des classes qui ne sont pas des threads indépendants, mais
instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
J'ai une application qui gère des espèces de plugin. Certains doivent pouvoir travailler indépendemment, d'autres pas forcément; mais tous génère un événement qui permet à mon application de réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un événement particulier sur une autre classe. Et quand il doit réagir, il génère lui-même l'événement qui sera intercepté par l'application principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus adaptées, en effet, avec le yield() ton thread peut se réveiller a n'importe quel moment ce qui n'est pas nécéssaire apparament. En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu fais un notify (le wait et le notify doivent etre dans des blocs synchronized avec un lock sur le meme objet afin que le notify réveille bien ton (ou tes) thread(s)
Si mon application n'est pas graphique, peut-on générer des événements dans des classes qui ne sont pas des threads indépendants, mais instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
Christophe M.
Kupee wrote:
Christophe M. wrote:
J'ai une application qui gère des espèces de plugin. Certains doivent pouvoir travailler indépendemment, d'autres pas forcément; mais tous génère un événement qui permet à mon application de réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un événement particulier sur une autre classe. Et quand il doit réagir, il génère lui-même l'événement qui sera intercepté par l'application principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus adaptées, en effet, avec le yield() ton thread peut se réveiller a n'importe quel moment ce qui n'est pas nécéssaire apparament. En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu fais un notify (le wait et le notify doivent etre dans des blocs synchronized avec un lock sur le meme objet afin que le notify réveille bien ton (ou tes) thread(s)
Si je comprends bien, faut faire, dans le run() :
while(_isnotfinished){ wait(monlock); //maintenant j'ai un truc à faire ... ... }
et dans le listener de mon thread qui est sensé gérer un événement, je fais :
void monevenement(Event evt){ notify(monlock); }
un truc comme ça ? Dans ce cas, l'événement est géré dans le run du thread en fait, non ?
Si mon application n'est pas graphique, peut-on générer des événements dans des classes qui ne sont pas des threads indépendants, mais instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
ma question est peut-être mal posée...
vu que finalement un événement est un méthode appelée sur un listener par un objet qui génère l'événement. Si il n'est pas dans un thread "séparé", quand aura-t-il la main, si ce n'est dans le cas ou le thread principale de l'application fait appel à une de ses méthodes ? Si "jamais", dans mon cas, ça n'arrivera pas, donc je dois pas le gérer comme celà...
Je vais donc préciser, que faut-il faire dans el déclenchement d'un événement ? : // en imaginant que listenerlist est un ArrayList de listener private void triggerMonEvent(Event evt){ for(int i = 0 ; i < listenerlist.size();i++){ ((Monlistener)listenerlist.get(i)).gèreMonEvent(evt); } }
ou bien : private void triggerMonEvent(Event evt){ for(int i = 0 ; i < listenerlist.size();i++){ EventQueue.invokeLater( new Runnable(){ public void run(){ ((Monlistener)listenerlist.get(i)).gèreMonEvent(evt); } } } } }
Si c'est la solution 2, je vais galérer avec la gestion multi-thread :-)
Kupee wrote:
Christophe M. wrote:
J'ai une application qui gère des espèces de plugin.
Certains doivent pouvoir travailler indépendemment, d'autres pas
forcément; mais tous génère un événement qui permet à mon application
de réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un
événement particulier sur une autre classe. Et quand il doit réagir,
il génère lui-même l'événement qui sera intercepté par l'application
principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus
adaptées, en effet, avec le yield() ton thread peut se réveiller a
n'importe quel moment ce qui n'est pas nécéssaire apparament.
En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu
fais un notify (le wait et le notify doivent etre dans des blocs
synchronized avec un lock sur le meme objet afin que le notify réveille
bien ton (ou tes) thread(s)
Si je comprends bien, faut faire, dans le run() :
while(_isnotfinished){
wait(monlock);
//maintenant j'ai un truc à faire
...
...
}
et dans le listener de mon thread qui est sensé gérer un événement, je
fais :
void monevenement(Event evt){
notify(monlock);
}
un truc comme ça ?
Dans ce cas, l'événement est géré dans le run du thread en fait, non ?
Si mon application n'est pas graphique, peut-on générer des événements
dans des classes qui ne sont pas des threads indépendants, mais
instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
ma question est peut-être mal posée...
vu que finalement un événement est un méthode appelée sur un listener
par un objet qui génère l'événement. Si il n'est pas dans un thread
"séparé", quand aura-t-il la main, si ce n'est dans le cas ou le thread
principale de l'application fait appel à une de ses méthodes ?
Si "jamais", dans mon cas, ça n'arrivera pas, donc je dois pas le gérer
comme celà...
Je vais donc préciser, que faut-il faire dans el déclenchement d'un
événement ? :
// en imaginant que listenerlist est un ArrayList de listener
private void triggerMonEvent(Event evt){
for(int i = 0 ; i < listenerlist.size();i++){
((Monlistener)listenerlist.get(i)).gèreMonEvent(evt);
}
}
ou bien :
private void triggerMonEvent(Event evt){
for(int i = 0 ; i < listenerlist.size();i++){
EventQueue.invokeLater(
new Runnable(){
public void run(){
((Monlistener)listenerlist.get(i)).gèreMonEvent(evt);
}
}
}
}
}
Si c'est la solution 2, je vais galérer avec la gestion multi-thread :-)
J'ai une application qui gère des espèces de plugin. Certains doivent pouvoir travailler indépendemment, d'autres pas forcément; mais tous génère un événement qui permet à mon application de réagir à un certain moment.
Exemple simple : un plugin ne fait rien, si ce n'est attendre un événement particulier sur une autre classe. Et quand il doit réagir, il génère lui-même l'événement qui sera intercepté par l'application principale.
Dans ton cas peut etre que les méthodes wait et notify seraient plus adaptées, en effet, avec le yield() ton thread peut se réveiller a n'importe quel moment ce qui n'est pas nécéssaire apparament. En gros tu mettrais ton thread en wait, et lorsqu'on evenement arrive tu fais un notify (le wait et le notify doivent etre dans des blocs synchronized avec un lock sur le meme objet afin que le notify réveille bien ton (ou tes) thread(s)
Si je comprends bien, faut faire, dans le run() :
while(_isnotfinished){ wait(monlock); //maintenant j'ai un truc à faire ... ... }
et dans le listener de mon thread qui est sensé gérer un événement, je fais :
void monevenement(Event evt){ notify(monlock); }
un truc comme ça ? Dans ce cas, l'événement est géré dans le run du thread en fait, non ?
Si mon application n'est pas graphique, peut-on générer des événements dans des classes qui ne sont pas des threads indépendants, mais instanciés dans le thread principal (celui de l'application )
Ca, ca dépend vraiment du fonctionnement de ton application je pense
ma question est peut-être mal posée...
vu que finalement un événement est un méthode appelée sur un listener par un objet qui génère l'événement. Si il n'est pas dans un thread "séparé", quand aura-t-il la main, si ce n'est dans le cas ou le thread principale de l'application fait appel à une de ses méthodes ? Si "jamais", dans mon cas, ça n'arrivera pas, donc je dois pas le gérer comme celà...
Je vais donc préciser, que faut-il faire dans el déclenchement d'un événement ? : // en imaginant que listenerlist est un ArrayList de listener private void triggerMonEvent(Event evt){ for(int i = 0 ; i < listenerlist.size();i++){ ((Monlistener)listenerlist.get(i)).gèreMonEvent(evt); } }
ou bien : private void triggerMonEvent(Event evt){ for(int i = 0 ; i < listenerlist.size();i++){ EventQueue.invokeLater( new Runnable(){ public void run(){ ((Monlistener)listenerlist.get(i)).gèreMonEvent(evt); } } } } }
Si c'est la solution 2, je vais galérer avec la gestion multi-thread :-)
