multithread

multithread - Java - Programmation

Marsh Posté le 16-01-2004 à 15:37:32    

Un serveur doit lancer des traitements (trt) qui sont des threads.
 
Les trt en question implémentent une interface qui permet de les manipuler mais on ne connait pas du tout ces trt, ce qu'ils font etc... (De plus les classes de ces trt sont chargées dynamiquement).
 
Je veux limiter les nombre de threads que le serveur doit lancer.
A chaque fois que je lance un trt, je regarde si runningThreads<=maxThreads, j'incrémente runningThreads et je lance le trt.
 
Problème : n'ayant aucun contrôle sur ces trts, je ne sais pas quand ils s'arrêtent et donc quand je peux décrémenter mon compteur de threads.
Je n'ai pas la main sur le code des trt...
 
Une idée ?
 
 
 

Reply

Marsh Posté le 16-01-2004 à 15:37:32   

Reply

Marsh Posté le 16-01-2004 à 16:31:59    

Il faut que tu gères une classe qui va compter pour toi,
 
Cette classe contiendra un compteur static
 
Chaque Thread devra décrémenter le compteur de cette classe de comptage en se fermant
 
ça s'appelle singleton il me semble comme modèle de conception...


---------------
On ne vit qu'une fois, mais pour qui sait vivre, une seule fois suffit (Merril Stubbing)
Reply

Marsh Posté le 16-01-2004 à 16:35:44    

Citation :

Chaque Thread devra décrémenter le compteur de cette classe de comptage en se fermant


C'est bien là que le bât blaisse...
 
Je crois qu'il va falloir que je force les pti gars qui développent les trt à envoyer un signal à la fin de leur méthode run().

Reply

Marsh Posté le 16-01-2004 à 16:38:46    

oui, il faut qu'à la fin du run() des tâches, ils signalent la fin de la tâche, ça peut passer par un encapsulage du run() de ta tache ou du Runnable.
 
typiquement quelquepart tu auras ça :

Code :
  1. void run() {
  2.   tache.run();
  3.   decrementeNumTaches();
  4. }


 
Donne un peu plus de détails : quelle est cette interface ? tu utilises des Runnable ou des Thread ?  
Pour qu'on puisse te donner une réponse plus précise.
 
dernier détail au cas où : n'oublie pas que le seul moyen valable de tuer une tache est de terminer la méthode run(), toutes les autres sont risquées et vont être supprimées de java.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 16:45:44    

Dans la java doc, y'a une methode de la class Thread qui s'appelle "isAlive()":

Code :
  1. isAlive
  3. public final boolean isAlive()
  4. Tests if this thread is alive. A thread is alive if it has been started and has not yet died.
  6. Returns:
  7. true if this thread is alive; false otherwise.


 
Je pense que ça doit être ça!


Message édité par torpe23 le 16-01-2004 à 16:46:46
Reply

Marsh Posté le 16-01-2004 à 16:48:20    

Donc quand tu garde en mémoire un vecteur de tes threads lancés. Et quand tu veux en lancer un nouveau, si ton compteur est est au max, tu parcours ton vecteur pour voir si par hasard, y'en aurait pas un qui serait terminé!

Reply

Marsh Posté le 16-01-2004 à 16:50:52    

houlà, on est pas sur la même planète niveau complexité.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 16:51:22    

isAlive()... comment j'ai pu passer à côté !?
Oui, je peux me servir de ça : connstruire une List de mes threads et la parcourir de temps en temps, appeler isAlive et si true => je décrémente.
 
Merci.
 
Comme dirait JCD : "je crois que c'est mes yeux"

Reply

Marsh Posté le 16-01-2004 à 16:52:00    

nraynaud a écrit :

houlà, on est pas sur la même planète niveau complexité.


pourquoi ?

Reply

Marsh Posté le 16-01-2004 à 16:54:45    

krosso a écrit :


pourquoi ?

avec la bidouille isAlive, tu parcoures un tableau, avec la mienne, tu décrémentes un compteurs au bon moment.
En plus avec ton tableau tu vas garder des références sur les threads, donc limiter le GC. N'oublie pas au moins de mettre la case du tableau à null quand tu verras qu'une thread est morte.


Message édité par nraynaud le 16-01-2004 à 16:55:09

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 16:54:45   

Reply

Marsh Posté le 16-01-2004 à 16:58:27    

L'intérêt du isAlive() c'est que je ne dois pas intervenir dans le code des trts.
Tout ce que je connais de ces trts c'est leur interface et ses méthodes call() et run()
 
je n'ai aucun contrôle sur ce que les développeurs vont mettre dans leur méthodes run().
 
Il y a bien une spec que je vais distribuer.  
Mais même s'il est écrit n/b dans ma spec qu'il faut envoyer tel message à la fin de run(), tu peut être sûr qu'un gusse ne le fera pas et va me pourir mon compteur de threads... trop risqué.

Reply

Marsh Posté le 16-01-2004 à 17:00:17    

krosso a écrit :

L'intérêt du isAlive() c'est que je ne dois pas intervenir dans le code des trts.
Tout ce que je connais de ces trts c'est leur interface et ses méthodes call() et run()
 
je n'ai aucun contrôle sur ce que les développeurs vont mettre dans leur méthodes run().
 
Il y a bien une spec que je vais distribuer.  
Mais même s'il est écrit n/b dans ma spec qu'il faut envoyer tel message à la fin de run(), tu peut être sûr qu'un gusse ne le fera pas et va me pourir mon compteur de threads... trop risqué.

Je t'ai dit de nous donner au moins l'interface pour te montrer comment faire le proxy qui va bien.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 17:06:18    

nraynaud a écrit :

Je t'ai dit de nous donner au moins l'interface pour te montrer comment faire le proxy qui va bien.


Merci pour ton aide, mais la solution isAlive() me convient. Du moins vais-je la tester.
 
pour l'interface :
public interface IBatch extends Runnable
{
   public void call(Classe1 truc, Classe2 truc);
}


Message édité par krosso le 16-01-2004 à 17:06:47
Reply

Marsh Posté le 16-01-2004 à 17:07:53    

1) Récupérer un pool de thread dont tu fixes la taille max
 
2) faire un petit truc vite fait à la mimine :  

Code :
  1. package utils;
  3. public class ThreadPool {
  4.  
  5.    private PooledThread[] threads;
  6.    private Object lock = new Object();
  8. public ThreadPool(int maxThreads) {
  9.  this.threads = new PooledThread[maxThreads];
  10.  for (int i = 0; i < this.threads.length; i++) {
  11.   this.threads[i] = new PooledThread(i);
  12.   this.threads[i].setDaemon(true);
  13.   this.threads[i].start();
  14.  }
  15. }
  17. public synchronized void doWork(Runnable work) {
  18.       //search a ready thread
  19.  for (int i = 0; i < this.threads.length; i++) {
  20.   if (this.threads[i].isReady()) {
  21.    this.threads[i].doWork(work);
  22.    return;
  23.   }
  24.  }
  25.  // no threads found
  26.  try {
  27.   synchronized (this.lock) {
  28.    this.lock.wait();
  29.   }
  30.  } catch (InterruptedException e) {
  31.   Thread.currentThread().interrupt();
  32.   return;
  33.  }
  34.  // a thread as finished => do the work
  35.  doWork(work);
  36. }
  38. public synchronized void close() {
  39.  for (int i = 0; i < this.threads.length; i++) {
  40.   this.threads[i].end();
  41.   this.threads[i].interrupt();
  42.  }
  43. }
  44.  
  45. private class PooledThread extends Thread {
  47.  private Runnable work = null;
  48.  private boolean mustStop = false;
  49.  private boolean running = false;
  51.  public PooledThread(int nb) {
  52.   super("PooledThread " + nb);
  53.  }
  55.  public void end() {
  56.   this.mustStop = true;
  57.  }
  59.  public synchronized void doWork(Runnable work) {
  60.   if (this.work == null) {
  61.    this.work = work;
  62.    this.running = true;
  63.    this.notify();
  64.   } else {
  65.    // mauvaise utilisation
  66.    throw new RuntimeException("Thread Already running. Bad use" );
  67.   }
  68.  }
  70.  public synchronized boolean isReady() {
  71.   return ! running;
  72.  }
  75.  public void run() {
  76.   while (! mustStop) {
  77.    try {
  78.     synchronized (this) {
  79.      this.running = false;
  80.      this.work = null;
  81.      synchronized(ThreadPool.this.lock) {
  82.       //notify the pool that the trhread is ready
  83.       ThreadPool.this.lock.notify();
  84.      }
  85.      this.wait();
  86.     }
  87.    } catch (InterruptedException e) {
  88.     continue;
  89.    }
  90.    if (this.work != null) {
  91.     try {
  92.      this.work.run();
  93.     } catch (Throwable t) {
  94.      t.printStackTrace();
  95.     }
  96.     Thread.interrupted(); // clear the interrupt status
  97.    }
  98.   }
  99.        
  100.  }
  101. }
  102. /*
  103. // ------------------------------------- TEST ----------------
  104. public static void main(String[] args) throws Exception {
  105.  ThreadPool pool = new ThreadPool(3);
  106.  for (int i = 0; i < 10; i++) {
  107.   pool.doWork(new Test(i));
  108.   Thread.sleep(600);
  109.  }
  110. }
  112. public static class Test implements Runnable {
  113.  private int nb;
  114.  public Test(int nb) {
  115.   this.nb = nb;
  116.  }
  117.  
  118.  public void run() {
  119.   System.out.println("thread " + nb + "start" );
  120.   try {
  121.    Thread.sleep(2000);
  122.   } catch (InterruptedException e) {
  123.    // nothing
  124.   }
  125.   System.out.println("thread " + nb + "stop" );
  126.  }
  128. }
  129. */
  130. }


 
ca devrait marcher ...
 
edit : j'ai mit tant de temps que ca à l'écrire ce code ??? y avait pas de réponse quand j'ai commencé  [:mlc2]
edit2 : au moins 35 minutes [:w3c compliant]


Message édité par benou le 16-01-2004 à 19:04:31

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 17:16:22    

Diantre Benou, Je te remercie de te donner autant de mal !
 
Je te promets de regarder ça en détails.
Présentement je pars en week-end (bien mérité ma foi).
 

Reply

Marsh Posté le 16-01-2004 à 17:17:48    

benou > quand je fais un pool, je mets une pile qui ne contient que des objets libres. ça permet d'avoir tout en O(1).
 
 
edit : et accessoirement de réutiliser en priorité l'objet le plus récement utilisé.


Message édité par nraynaud le 16-01-2004 à 17:18:57

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 17:18:44    

krosso a écrit :

Diantre Benou, Je te remercie de te donner autant de mal !


ca faisait un moment que ca me démangeait de coder ca :D
 
quand j'aurais du courage je ferai la version qui augmente son pool de thread dynamiquement ;)


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 17:23:06    

nraynaud a écrit :

benou > quand je fais un pool, je mets une pile qui ne contient que des objets libres. ça permet d'avoir tout en O(1).
 
 
edit : et accessoirement de réutiliser en priorité l'objet le plus récement utilisé.


ouais je sais, je me suis pas fait chier, j'ai fait des boucles sur le tableau ... ce serait mieux avec une pile bien sûr (quoique l'implémentation Stack du JDK sux méchament)


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 17:27:56    

benou a écrit :


ouais je sais, je me suis pas fait chier, j'ai fait des boucles sur le tableau ... ce serait mieux avec une pile bien sûr (quoique l'implémentation Stack du JDK sux méchament)

j'ai même pas regardé, j'ai vu que c'était synchronized par défaut => on prend.
mais sinon, y'a ArrayList et LinkedList.
 
 
edit : mais c'est surtout que le code est plus court avec une pile.
C'est marrant cette tendance à avoir une complexité de daube et un code plus long quand "on veut pas se faire chier", des fois ça me fait pareil.


Message édité par nraynaud le 16-01-2004 à 17:29:19

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 19:01:00    

nraynaud a écrit :

j'ai même pas regardé, j'ai vu que c'était synchronized par défaut => on prend.
mais sinon, y'a ArrayList et LinkedList.


ben ca hérite de Vector :/
 

nraynaud a écrit :


edit : mais c'est surtout que le code est plus court avec une pile.
C'est marrant cette tendance à avoir une complexité de daube et un code plus long quand "on veut pas se faire chier", des fois ça me fait pareil.


ben nan c'est pas beaucoup plus court :  

Code :
  1. package utils;
  3. import java.util.Stack;
  5. public class ThreadPool2 {
  6.  
  7. private PooledThread[] threads;
  8. //private Object lock = new Object();
  9. private Stack readyThreads;
  11. public ThreadPool2(int maxThreads) {
  12.  this.threads = new PooledThread[maxThreads];
  13.  this.readyThreads = new Stack();
  14.  this.readyThreads.ensureCapacity(maxThreads);
  15.  for (int i = 0; i < this.threads.length; i++) {
  16.   this.threads[i] = new PooledThread(i);
  17.   this.threads[i].setDaemon(true);
  18.   this.threads[i].start();
  19.  }
  20. }
  22. public synchronized void doWork(Runnable work) {
  23.  PooledThread th;
  24.  try {
  25.   synchronized (this.readyThreads) {
  26.    if (this.readyThreads.isEmpty()) {
  27.     this.readyThreads.wait();
  28.    }
  29.    th = (PooledThread) this.readyThreads.pop();
  30.   }
  31.  } catch (InterruptedException e) {
  32.   Thread.currentThread().interrupt();
  33.   return;
  34.  }
  35.  // a thread as finished => do the work
  36.  th.doWork(work);
  37. }
  39. public synchronized void close() {
  40.  for (int i = 0; i < this.threads.length; i++) {
  41.   this.threads[i].end();
  42.   this.threads[i].interrupt();
  43.  }
  44.  this.readyThreads.clear();
  45. }
  46.  
  47. private class PooledThread extends Thread {
  49.  private Runnable work = null;
  50.  private boolean mustStop = false;
  52.  public PooledThread(int nb) {
  53.   super("PooledThread " + nb);
  54.  }
  56.  public void end() {
  57.   this.mustStop = true;
  58.  }
  60.  public synchronized void doWork(Runnable work) {
  61.   if (this.work == null) {
  62.    this.work = work;
  63.    this.notify();
  64.   } else {
  65.    // mauvaise utilisation
  66.    throw new RuntimeException("Thread Already running. Bad use" );
  67.   }
  68.  }
  70.  public void run() {
  71.   while (! mustStop) {
  72.    try {
  73.     synchronized (this) {
  74.      this.work = null;
  75.      synchronized(ThreadPool2.this.readyThreads) {
  76.       //notify the pool that the thread is ready
  77.       ThreadPool2.this.readyThreads.push(this);
  78.       ThreadPool2.this.readyThreads.notify();
  79.      }
  80.      this.wait();
  81.     }
  82.    } catch (InterruptedException e) {
  83.     continue;
  84.    }
  85.    if (this.work != null) {
  86.     try {
  87.      this.work.run();
  88.     } catch (Throwable t) {
  89.      t.printStackTrace();
  90.     }
  91.     Thread.interrupted(); // clear the interrupt status
  92.    }
  93.   }
  94.        
  95.  }
  96. }
  97. /*
  98. public static void main(String[] args) throws Exception {
  99.  ThreadPool2 pool = new ThreadPool2(3);
  100.  for (int i = 0; i < 10; i++) {
  101.   pool.doWork(new Test(i));
  102.   Thread.sleep(600);
  103.  }
  104. }
  106. public static class Test implements Runnable {
  107.  private int nb;
  108.  public Test(int nb) {
  109.   this.nb = nb;
  110.  }
  111.  
  112.  public void run() {
  113.   System.out.println("thread " + nb + "start" );
  114.   try {
  115.    Thread.sleep(2000);
  116.   } catch (InterruptedException e) {
  117.    // nothing
  118.   }
  119.   System.out.println("thread " + nb + "stop" );
  120.  }
  122. }
  123. */
  124. }


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:04:04    

au fait, j'avais oublié de mettre les thread daemon :/


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:09:55    

[:prosterne] benou [:prosterne2]


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 16-01-2004 à 19:10:37    

Voir aussi du coté des ThreadsGroup. Comme son nom l'indique, permet de faire des groupes de threads. Ensuite, il existe une fonction nommé "activeCount()" qui renvoie le nb de Thread qui tourne dans le groupe. Bref... A voir, quoi!


Message édité par torpe23 le 16-01-2004 à 19:11:03
Reply

Marsh Posté le 16-01-2004 à 19:12:56    

torpe23 a écrit :

Voir aussi du coté des ThreadsGroup.


je me suis jamais servi de ce machin là  :sweat:


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:13:09    

Harkonnen a écrit :

[:prosterne] benou [:prosterne2]


c'est fini oui ???  :D


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:13:51    

moi non plus, mais ça a l'air d'être la solution pourtant!
Pkoi refaire ce que d'autre ont déja fait?!

Reply

Marsh Posté le 16-01-2004 à 19:16:22    

torpe23 a écrit :

Pkoi refaire ce que d'autre ont déja fait?!  


heu non, le threadgroup n'a rien à voir avec un pool de thread ...


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:17:22    

pkoi pas?

Reply

Marsh Posté le 16-01-2004 à 19:22:18    

torpe23 a écrit :

pkoi pas?


ben c'est pas les mêmes fonctionnalités, c'est tout [:spamafote]
 
Le pool de thread répond bien mieux à ton besoin. En plus, il t'évite de relancer un nouveau thread à chaque traitement : il utilise tjs les mêmes


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:25:12    

benou > on était pas sur la même longueur d'onde.  
 
Bon ça devient jacky-threadpool, donc je vais étudier la solution qui m'est venue à l'esprit. Mais on est clairement sorti du "vite fait", d'un autre côté, ça peut me servir dans peu de temps.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 19:30:52    

Harkonnen a écrit :

[:prosterne] benou [:prosterne2]


 
c'est vrai qu'il est sacrement balaise benou [:icon7] meilleur que moins moins en tout cas [:icon11]

Reply

Marsh Posté le 16-01-2004 à 19:31:12    

benou a écrit :


je me suis jamais servi de ce machin là  :sweat:  

et tu t'étonnes que je te raille quand on te prend pour un génie [:kiki]


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 16-01-2004 à 19:31:26    

nraynaud a écrit :

benou > on était pas sur la même longueur d'onde.  


ha  :??:  
 
je vois pas ce que tu voulais dire avec la pile alors ... :/


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:32:10    

the real moins moins a écrit :

et tu t'étonnes que je te raille quand on te prend pour un génie [:kiki]


pardon maître  [:prosterne2]


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 19:33:09    

je vais faire un truc et tu me diras ce que tu en penses, j'ai encore quasiment rien fait avec les threads en java pour l'instant.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 19:37:37    

nraynaud a écrit :

je vais faire un truc et tu me diras ce que tu en penses


ca roule :)


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 20:16:25    

En fait non, laisse béton, je ferais pas mieux.
peut-être en remettant un close dans le finalize et en virant le catch universel (j'ai horreur de ça, ça fout les debuggeurs en vrac), mais sinon rien.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 20:31:09    

nraynaud a écrit :


peut-être en remettant un close dans le finalize


ouais ...
 

nraynaud a écrit :

et en virant le catch universel (j'ai horreur de ça, ça fout les debuggeurs en vrac), mais sinon rien.


ca non, faut pas ! Si tu fais ca tu flingues tes threads au fur et à mesure !
Qu'est ce que tu voudrais mettre à la place ? De toute façon à ce niveau là tu ne peux rien faire d'autre que de stacktracer l'erreur ... C'est ce que ferais un vrai thread avant de se laisser mourrir [:spamafote] là je sauve juste mon thread :)
 
et c'est quoi le problème avec les débuggueur  :??:


Message édité par benou le 16-01-2004 à 20:32:07

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 16-01-2004 à 20:47:07    

benou a écrit :


ca non, faut pas ! Si tu fais ca tu flingues tes threads au fur et à mesure !
Qu'est ce que tu voudrais mettre à la place ? De toute façon à ce niveau là tu ne peux rien faire d'autre que de stacktracer l'erreur ... C'est ce que ferais un vrai thread avant de se laisser mourrir [:spamafote] là je sauve juste mon thread :)
 
et c'est quoi le problème avec les débuggueur  :??:  

tu laisses mourrir ton thread et tu en recrées un autre ? (dans le catch tu recrées le nouveau thread, tu règles tout au niveau du pool et tu relances l'exception).
 
Les debuggeurs s'arrêtent au point de départ de l'exception et ça permet de debugger. Sinon c'est comme swing : la merde à debugger (à coup de breakpoints dans Throwable()). Car si on bouffe l'exception, on n'a qu'une trace dans la sortie standard, un peu mince comme indice du problème.
 
Aussi j'aurais fait une création lazy (au besoin) des threads.
 
Et puis mettre un close() finalize c'est une connerie, à cause du pointeur vers l'objet englobant.


Message édité par nraynaud le 16-01-2004 à 20:49:50

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 16-01-2004 à 21:38:13    

nraynaud a écrit :

tu laisses mourrir ton thread et tu en recrées un autre ? (dans le catch tu recrées le nouveau thread, tu règles tout au niveau du pool et tu relances l'exception).


et c'est quoi l'intérêt ?????
 

nraynaud a écrit :


Les debuggeurs s'arrêtent au point de départ de l'exception et ça permet de debugger. Sinon c'est comme swing : la merde à debugger (à coup de breakpoints dans Throwable()). Car si on bouffe l'exception, on n'a qu'une trace dans la sortie standard, un peu mince comme indice du problème.


??? mais ca reviendrait exactement au même que je laisse passer l'exception ... je comprend pas ce que tu veux dire ... En quoi le debuggueur se comporterait différement ?
 
si le mec veut intercepter les erreur, il peut le faire au niveau du traitement ... Quand n runnable plante, si tu laisse passer l'exception à traers le run, tu n'as plus aucun contrôle ... Donc je vois pas en quoi c'est gênent que moi je la catche après [:spamafote]
 

nraynaud a écrit :


Aussi j'aurais fait une création lazy (au besoin) des threads.


ouais, c'est ce que je disais quand je parlais d'une dynamisation du pool de thread. En même temps là, tu gagne en perf : les threads sont créés à l'initialisation => le pool est plus réactif ... Tu penses que ca vouffe bcp de ressource un thread en pause ?
 

nraynaud a écrit :


Et puis mettre un close() finalize c'est une connerie, à cause du pointeur vers l'objet englobant.


?? hein ?
c'est dans le finalize du pool qu'il faut mettre le close, pas dans les Pooled Thread.


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed