Echange processus A <-> threads B

Bonjour,

J'utilise actuellement une API multithreads de rendu 3D, qui existe en version Linux et Windows.

Le moteur de rendu calcule l'image par morceaux, qu'on appelle "tuiles".

Mon application utilisant cet API tourne dans son propre processus, et appelle la DLL de ce moteur de rendu, qui a également son processus. Lors d'une demande de rendu, le moteur de rendu crée n threads, et chacun renvoie la "tuile" calculée au processus appelant (mon appli). Sauf que mon appli ne les reçoit jamais...

Ce comportement malheureux n'a lieu que sous Windows; ça fonctionne très bien sous Linux.

La question est donc la suivante : dans un environnement Windows, un processus A peut-il dialoguer avec les threads d'un processus B ?

Merci !

Il y a tout plein de méthodes de communication inter-processus sous Windows.
Par contre, on ne sait pas quelle(s) est(sont) la(les) méthode(s) de communication employée(s) par ton moteur de rendu...

Voici la ligne de création de thread :

Code:

---

1 2 3 4 5

handle = (HANDLE)_beginthreadex(NULL, 0, (unsigned int (__stdcall *)(AtVoid *))fn, data, CREATE_SUSPENDED, &thread_ID );

---

fn est la fonction qui doit recevoir le résultat du calcul.
Je ne pense pas que le reste soit important pour vous.

Je n'ai pas demandé la façon dont était créé le thread (par contre, il est créé dans quel processus et par quoi?).

De plus, mettre un cast de pointeur de fonction comme ça, c'est vraiment, vraiment crade.

Citation:

---

Envoyé par Médinoc

De plus, mettre un cast de pointeur de fonction comme ça, c'est vraiment, vraiment crade.

---

++1 (et ça sent les problèmes)

En plus, ton thread, il est créé dans l'état "suspendu". J'espère que quelqu'un ailleurs pense à le reveiller.

Citation:

---

Envoyé par Médinoc

Je n'ai pas demandé la façon dont était créé le thread (par contre, il est créé dans quel processus et par quoi?).

---

Le processus A demande au processus B : "Lance moi un rendu en utilisant n threads."
Le pocessus B crée alors ses threads en bouclant sur le nombre de threads demandé.
Chaque thread se voit alors affecté une tuile à calculer, et le thread renvoit (ou plutôt essaye...) cette tuile vers le processus B. Mais la communication ne se fait pas, manifestement.

Citation:

---

Envoyé par Médinoc

De plus, mettre un cast de pointeur de fonction comme ça, c'est vraiment, vraiment crade.

---

Ca m'avait également paru bizarre qu'il fasse ça. Mais bon, je n'ai pas trop la main sur le code...

Citation:

---

Envoyé par ram_0000

En plus, ton thread, il est créé dans l'état "suspendu". J'espère que quelqu'un ailleurs pense à le reveiller.

---

Oui oui. C'est juste parce que juste après la création est settée la priorité du thread. Ensuite, el thread est "résumé".

Donc, ce code de création, il est dans B ?
Alors que fait-il avec la fonction "qui doit recevoir le résultat du calcul", comme tu dis?

J'ai effectivement dit une grosse connerie.
fn est la fonction qui effectue le calcul, pas celle qui le reçoit.

Le moteur de rendu, A, a connaissance d'un pointeur de fonction fnPt.
Cette information a été "settée" à un moment antérieur, peu importe quand.

Ensuite, on décide de lancer un rendu :

- A appelle B, en lui demandant d'utiliser n threads
- B crée commence une boucle, créant les n threads (B.1, B.2...) en état suspendu
- dans cette boucle est "settée" la priorité du thread, puis le thread courant est lancé
- B.k, lorsqu'il a terminé son calcul, passe sa "tuile" à la fonction fnPt définie dans A

Cette dernière étape fonctionne sous Linux, mais pas sous Windows. Les tuiles ne sont jamais reçues.

Désolé de ne pouvoir vous filer du code, mais ce n'est pas le mien. Notre fournisseur d'API m'en a gracieusement passé des morceaux, mais je ne suis pas supposé les diffuser... :-(
Mais comme il n'est guère motivé pour se creuser la tête pour la plate-forme Windows, je fais néanmoins appel à vous. :-)

Comment est "setté" ce pointeur de fonction, et comment est-il appelé ?
Je suppose qu'il est mémorisé du côté "bibliothèque chargée dans A" et qu'il est appelé par cette même bibliothèque sur réception d'un "message" de B, non?

Comment est envoyé ce "message" ? Quelle est la méthode de communication entre A et B ?

• sockets ?
• mémoire partagée ?
• messages Windows ?
• tubes ?
• etc.

A vrai dire, je ne peux pas répondre à ces questions : je n'ai pas accés au code. Et de toute façon, je n'y connais quasiment rien en programmation multithread. Je n'ai donc pas l'intention de vous demander une solution.

Je voulais juste m'assurer qu'il était possible que des threads "hébergés" par un processus B pouvaient communiquer avec un autre processus A, ou si la communication pouvait se faire uniquement entre processus.

Comme le codeur de l'API code surtout du Linux, je m'étais dit qu'il essayait peut-être de copier dans son code Windows un mode de fonctionnement possible uniquement sur Linux. Dans ce cas là, j'essaierai de l'encourager à sérialiser le résultat des calculs avant de les envoyer par le thread principal de B (le processus...).

Citation:

---

Envoyé par oodini

Je voulais juste m'assurer qu'il était possible que des threads "hébergés" par un processus B pouvaient communiquer avec un autre processus A, ou si la communication pouvait se faire uniquement entre processus.

---

Cette question est un non-sens: Les threads font partie du processus.
Chaque processus possède au moins un thread, et la définition même du thread c'est que du code s'exécute. Donc, le code ne s'exécute jamais en dehors d'un thread.

Citation:

---

Comme le codeur de l'API code surtout du Linux, je m'étais dit qu'il essayait peut-être de copier dans son code Windows un mode de fonctionnement possible uniquement sur Linux. Dans ce cas là, j'essaierai de l'encourager à sérialiser le résultat des calculs avant de les envoyer par le thread principal de B (le processus...).

---

Eh bien tant qu'on ne sait pas quel moyen de communication inter-processus il utilise, ce ne sera pas évident d'aider...

Citation:

---

Envoyé par Médinoc

Cette question est un non-sens: Les threads font partie du processus.
Chaque processus possède au moins un thread, et la définition même du thread c'est que du code s'exécute. Donc, le code ne s'exécute jamais en dehors d'un thread.

---

Mais le thread minimal auquel tu fais allusion n'a-t-il pas un statut spécial ? Du genre "thread principal", par rapport aux autres threads dotn il demande la création ?

Citation:

---

Envoyé par Médinoc

Eh bien tant qu'on ne sait pas quel moyen de communication inter-processus il utilise, ce ne sera pas évident d'aider...

---

Je veux simplement savoir s'il existe un moyen, n'importe lequel, pour qu'on thread "secondaire" d'un processus B envoie des données au thread "principal" d'un processus A.

Si on est d'accord sur le sens de ma question, un "oui" ou un "non" me suffira. :-)

Sous Windows en tout cas, y'a pas de thread "principal" ou non, sauf pour certaines choses très particulières qui considèrent le premier thread comme le thread principal (notamment certains objets COM).
La seule particularité, c'est que si main() retourne, le processus se termine. Mais si le premier thread est interompu de l'intérieur avec la fonction ExitThread(), les autres threads restent en vie et le programme se terminera normalement quand le dernier thread se terminera.

N'importe quel thread d'un processus peut communiquer avec n'importe quel autre thread d'un processus du même utilisateur.

OK, merci beaucoup !