Discussion :

[Bayard]

Bonsoir

Je sais communiquer avec un thread via un event (les exemples ne manquent pas).

J'ai lu la doc:
http://docs.python.org/library/threading.html

J'aimerais savoir comment enrichir la communication :

• soit passer des paramètres à l'évènement
• soit être capable de fournir plusieurs "events" différent à un thread: hélas il me semble que la fonction wait() ne permette d'attendre qu'un seul event à la fois (je ne compte pas faire des wait avec time-out).

Merci

[PauseKawa]

Bonjour,

Je ne vois pas ou est le problème.
Pour passer des paramètres tu utilise des méthodes, voir à la limite tu modifie directement les variables de ton instance thread (merci self).
Pour ce qui est de se que tu appelle event tu utilise des variables ou des instances threading.Event(), peut importe. Par contre oui, wait est lié à l'instance threading.Event(). Mais rien ne t'empêche d'en utiliser une comme flag (pour ton wait ou une boucle) et de la positionner lorsque tes conditions sont ok.

Bon code

[tyrtamos]

Bonjour,

En ce qui me concerne, j'utilise le plus souvent des verrous (Lock) qui permettent aux threads d'accéder à une ou plusieurs variables de manière fiable (http://python.jpvweb.com/mesrecettes...ion_par_thread). On arrive, par exemple, à simuler un 'tableau blanc' qui permet à un ensemble de threads de lire/écrire des informations mises en commun afin de simuler le fonctionnement d'un atelier, ou un jeu à plusieurs joueurs. Pour l'instant, ces mécanismes m'ont semblé suffisants: que cherches-tu à faire de plus?

Sinon, les bibliothèques graphiques, de par leur principe (programmation par évènements), peuvent permettre des échanges plus élaborés par transmission de messages entre les threads (connect/emit de PyQt4 par exemple), le message pouvant d'ailleurs être accompagné par des données Python quelconques. Par exemple, un thread peut, en émettant un message avec le résultat d'un calcul, provoquer le lancement d'une méthode du programme principal pour exploitation de ce résultat. Par contre, ces threads ne peuvent pas, en général, contenir des instructions graphiques.

Tyrtamos

[Bayard]

Je ne vois pas ou est le problème.

En donnant des paramètres via une méthode, je désynchronise l'évent et ses paramètres.
En d'autres termes, si j'émets 2 events simultanés en écrivant à chaque fois la valeur du paramètre, lors de la réception du premier event j'aurais le paramètre du second.

Le tableau blanc de Tyrtamos semble répondre au besoin.

[wiztricks]

Salut,
Regardez aussi les Queue qui sont un peu moins "basiques".
- W

[tyrtamos]

Bonjour wiztricks,

Regardez aussi les Queue qui sont un peu moins "basiques".

J'ai déjà tenté d'utiliser ce module queue, mais je le trouve très limité. Ou je n'ai pas trouvé comment l'utiliser. Par exemple:

- peut-on lire une info sans la détruire?

- peut-on lire/modifier/détruire une info à l'intérieur de la pile?

Tyrtamos

[wiztricks]

Salut Tyrtamos,

La fonction de base de ces objets est de construire un FIFO entre threads qui ressemblent à des pipes ou des mailboxes si on considère leurs équivalents OS.
- et une grosse différence aussi puisque pas besoin de sérialiser dans ce cas -.

Les fonctionnalités que tu souhaites:

- peut-on lire une info sans la détruire?
- peut-on lire/modifier/détruire une info à l'intérieur de la pile?

sont supportées par collections.deque.
- W

[tyrtamos]

Bonjour wiztricks,

Les fonctionnalités que tu souhaites sont supportées par collections.deque.

Merci. Je ne connaissais pas.

Effectivement, collections.deque peut remplacer la pile FIFO que j'utilise dans mon tableau blanc. Et comme ça ne semble pas être codé en Python (je suppose en C), on doit gagner en rapidité. Mais il faut être sûr d'utiliser un Python récent: certaines méthodes ont été modifiées en v. 2.6 et d'autres sont arrivées avec la v 2.7.

Tyrtamos