realbasic-nug.fr
[Top] [All Lists]

Re: Lancement de threads dans une boucle...

To: REALbasic NUG French <realbasic-nug dot fr at lists dot realsoftware dot com>
Subject: Re: Lancement de threads dans une boucle...
From: Arnaud Nicolet <anic297 at mac dot com>
Date: Tue, 20 Nov 2007 13:04:40 +0100
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug dot fr at lists dot realsoftware dot com
References: <4EE943A2-0AB7-49CD-8CF9-30488C44887D at e-topics dot net> <AB948EBD-BED9-4618-A0A4-51352B5344B8 at mac dot com> <p06240801c36863e53992 at [62 dot 161 dot 36 dot 122]>
Le 20 nov. 07 à 11:24 matin, Jean-Luc Arnaud a écrit:

Pourquoi ne pas utiliser le même "thread" uniquement?

Vous pourriez même le réinitialiser au démarrage si les propriétés le requièrent:

dim MyThread As new ThreadRef

for i=0 to 10
myThread.Initialize
myThread.Run
next

De mémoire, le problème avec votre code est que votre ancien "thread" est perdu lorsque le nouveau est créé (le "new ThreadRef" créé un nouveau "thread" mais l'ancien n'est plus référencé (il n'y a plus de variables qui y font référence). Du coup, il n'est plus en mémoire (il n'existe plus)). C'est la théorie en général pour les objets, peut-être avec de la chance, RealBasic mémorise les "thread" en interne et ce serait bon.


Bonjour,

Excuse-moi, Arnaud, mais je ne suis pas d'accord avec ta vision des choses.

Pas de problème.

L'instanciation d'un nouveau Thread portant le même nom crée bien un nouveau Thread, sans détruire ni gêner les autres Threads portant le même nom. Cela se passe comme pour un objet classique type bouton, fenêtre ou tout autre. Après, le problème est d'accéder au bon Thread, mais le ThreadID est là pour ça. En général, un Thread tourne de façon autonome, il n'est donc pas nécessaire de communiquer avec lui, d'autant qu'il est difficile de savoir où il en est dans son exécution. L'essentiel des échanges entre un Thread et la tâche principale concerne son statut (State), son arrêt/suspension/... (Kill, Sleep, Suspend, ...) et éventuellement son niveau de priorité (Priority). Pour ma part, dans une appli pro commercialisée, je lance jusqu'à 32 Thread de même nom, sans souci.


Je n'étais pas sûr pour les threads (c'est pour ça que j'ai dit "peut- être avec de la chance, RealBasic mémorise les "thread" en interne et ce serait bon" parce que c'est justement le cas).

Histoire de confirmer ce que j'ai dit, voici comment on peut voir ça:
On ajoute une nouvelle classe au projet (Nom: "Tim1", super: "Timer"). Dans cette nouvelle classe, on ajoute une propriété ("Test As Integer") et on rempli l'événement "Action" de la sorte:
  if Test=1 then
    MsgBox "1"
  else
    MsgBox "0"
  end if
Ensuite, on va dans la classe "app" et on ajoute une propriété ("MyTimer As Tim1"). On rempli ensuite l'événement "Open" de la classe "App" comme ça:
  MyTimer=new Tim1
  MyTimer.Test=1
  MyTimer.Mode=2
  MyTimer.Period=2000
(Donc on a un "Timer" qui affiche "1" toutes les 2 secondes).
Enfin, dans la fenêtre par défaut, on rempli l'événement "MouseDown" de la sorte:
  app.MyTimer=new Tim1
  app.MyTimer.Mode=2
  app.MyTimer.Period=2000
En faisant marcher le projet, on s'aperçoit qu'on voit "1" toutes les deux secondes jusqu'à ce qu'on clique sur la fenêtre. Ensuite, on ne voit que le "0", donc le premier "Timer" a disparu.

Pour les fenêtres et les contrôles c'est la même chose, seulement RealBasic garde une référence aux fenêtres ouvertes (donc, même si la variable ayant servi à créer la fenêtre disparaît du code, il subsiste une référence à la fenêtre "en interne"). Je viens d'apprendre que les "threads" sont aussi mémorisés de la même manière. Ma réserve lors de ma réponse était justifiée.

Ceci dit, je suis désolé d'avoir répondu à côté. La règle générale ne s'applique pas aux Threads et je ne savais pas. Milles excuses.

<Prev in Thread] Current Thread [Next in Thread>