Bonjour,
J'ai un souci avec les Thread et les API.
Je m'explique car c'est un peu compliqu=E9 :
J'ai fait une application serveur qui fait appel =E0 une DLL que j'ai
=E9crite en Visual C++, je lui passe deux chaines, une en entr=E9e et une
en retour qui sont envoy=E9 vers un service. Si je fait passer des
donn=E9es DEPUIS la fen=EAtre du serveur, tout ce passe bien, mais c'est
pas le but du syst=E8me.
Dans ce serveur, j'ai =E9crit des fonctions de transfert pas socket (pas
celle de Windev qui sont trop lente), mais je passe par la DLL
wsock32.dll, ces fonction sont dans des thread et c'est l=E0 que =E7a
marche plus.
Si je fait passer ces m=EAme donn=E9es par un client, le serveur r=E9cup=E8=
re
bien ces donn=E9es et les envoi =E0 la DLL VC++, mais celle ci me retourne
une erreur. Hors en pla=E7ant des traces/log partout (Serveur et DLL VC+
+), les valeurs des chaines sont bonnes. J'ai essay=E9 de mettre les
variables pass=E9 =E0 la DLL VC++ en global, c'est pareil :-(
Par contre, si je ne met pas la r=E9ception socket en thread, =E7a marche,
mais, la r=E9ception (accept,recv de wsock32.dll) est bloquante et donc
bloque le programme pour d'autres taches.
Bon je ne sais pas si je me suis bien fait comprendre, mais si
quelqu'un =E0 une id=E9e, je suis preneur, =E7a fait deux jour que je
gal=E8re.
Merci d'avance
Vincent
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
VincentBarre
Bon, je me répond à moi même. En fait, c'est une histoire d'appel de la même DLL dans des thread différents, je n'ai pas pu mettre ma DLL en mode single-thread (safemode), donc je suis obligé de l'initialiser et l'appeler dans le même thread. Je vais donc faire l'inverse, mettre la gestion de la fenêtre dans un thread... @+ Vincent
Bon, je me répond à moi même.
En fait, c'est une histoire d'appel de la même DLL dans des thread
différents, je n'ai pas pu mettre ma DLL en mode single-thread
(safemode), donc je suis obligé de l'initialiser et l'appeler dans le
même thread. Je vais donc faire l'inverse, mettre la gestion de la
fenêtre dans un thread...
@+
Vincent
Bon, je me répond à moi même. En fait, c'est une histoire d'appel de la même DLL dans des thread différents, je n'ai pas pu mettre ma DLL en mode single-thread (safemode), donc je suis obligé de l'initialiser et l'appeler dans le même thread. Je vais donc faire l'inverse, mettre la gestion de la fenêtre dans un thread... @+ Vincent
Eric LAURENT
Bonjour Vincent,
Vérifie que la fonction ThreadMode(threadSectionCritique) soit bien dans le code d'ouverture du projet.
Eric.
Bonjour Vincent,
Vérifie que la fonction ThreadMode(threadSectionCritique) soit bien
dans le code d'ouverture du projet.
Vérifie que la fonction ThreadMode(threadSectionCritique) soit bien dans le code d'ouverture du projet.
Eric.
patrice
Le 28/10/2011 11:38, VincentBarre a écrit :
Bon, je me répond à moi même. En fait, c'est une histoire d'appel de la même DLL dans des thread différents, je n'ai pas pu mettre ma DLL en mode single-thread (safemode), donc je suis obligé de l'initialiser et l'appeler dans le même thread. Je vais donc faire l'inverse, mettre la gestion de la fenêtre dans un thread... @+ Vincent
c'est quoi ton histoire de single thread ? je fait des dll en c++ et j'ai aucun soucis avec les threads. Il faut juste ne pas utiliser de globale mais une structure par thread que tu déclare dans la fonction principale du thread. Et coté windev, comme dit précédemment, ne pas utiliser la gestion auto des sections critiques
Si tu commence à mettre des affichages dans des thread en windev, ca va se compliquer franchement.
si tu t'en sors toujours pas avec les thread, utilise la fonction select() pour les sockets Comme ca tu les passes en non bloquant, et le select() te permet de savoir où tu en es.
Le 28/10/2011 11:38, VincentBarre a écrit :
Bon, je me répond à moi même.
En fait, c'est une histoire d'appel de la même DLL dans des thread
différents, je n'ai pas pu mettre ma DLL en mode single-thread
(safemode), donc je suis obligé de l'initialiser et l'appeler dans le
même thread. Je vais donc faire l'inverse, mettre la gestion de la
fenêtre dans un thread...
@+
Vincent
c'est quoi ton histoire de single thread ?
je fait des dll en c++ et j'ai aucun soucis avec les threads.
Il faut juste ne pas utiliser de globale mais une structure par thread
que tu déclare dans la fonction principale du thread.
Et coté windev, comme dit précédemment, ne pas utiliser la gestion auto
des sections critiques
Si tu commence à mettre des affichages dans des thread en windev, ca va
se compliquer franchement.
si tu t'en sors toujours pas avec les thread, utilise la fonction
select() pour les sockets
Comme ca tu les passes en non bloquant, et le select() te permet de
savoir où tu en es.
Bon, je me répond à moi même. En fait, c'est une histoire d'appel de la même DLL dans des thread différents, je n'ai pas pu mettre ma DLL en mode single-thread (safemode), donc je suis obligé de l'initialiser et l'appeler dans le même thread. Je vais donc faire l'inverse, mettre la gestion de la fenêtre dans un thread... @+ Vincent
c'est quoi ton histoire de single thread ? je fait des dll en c++ et j'ai aucun soucis avec les threads. Il faut juste ne pas utiliser de globale mais une structure par thread que tu déclare dans la fonction principale du thread. Et coté windev, comme dit précédemment, ne pas utiliser la gestion auto des sections critiques
Si tu commence à mettre des affichages dans des thread en windev, ca va se compliquer franchement.
si tu t'en sors toujours pas avec les thread, utilise la fonction select() pour les sockets Comme ca tu les passes en non bloquant, et le select() te permet de savoir où tu en es.
