leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 2010
-
14 nov. 2007 à 08:45
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 2010
-
20 nov. 2007 à 19:47
Bonjour,
Bon je vais tenter d'expliquer mon problème clairement (ca va pas être simple).
J'ai une application qui a une partie C# et une partie C++. Dans un event provenant de l'IHM (admettons une touche appuyée), on appelle une méthode C# qui appelle une méthode du C++ qui peut être longue (plusieurs dizaines de secondes). Et c'est la que ca coince...
Lorsqu'on appelle la méthode du C++, le marshaller fait sa tambouille et si on regarde la stack d'appelle, il réappelle la WndProc (et j'imagine qu'il lance la fonction C++ dans un autre thread). Comme ca a l'air de rien, le problème c'est que si l'utilisateur maintient la touche appuyée sans la relacher, on arrive rapidement a une stackoverflow exception (d'autant que cest en compact framework, donc sur une machine avec très peu de RAM et bcp déjà utilisée...
Pour essayer d'être plus clair, j'ai un truc du genre :
Si on regarde la stack d'appel lorsque l'utilisateur maintient appuyé (ce qui dans le contexte de mon appli est une utilisation normale), on a :
MonEventTouche()
MaMethodCsharp()
MaMethodNative() //on suppose en parallele
WndProc()
MonEventTouche()
MaMethodCsharp()
MaMethodNative() //on suppose en parallele
WndProc()
MonEventTouche()
MaMethodCsharp()
MaMethodNative() //on suppose en parallele
WndProc()
MonEventTouche()
MaMethodCsharp()
MaMethodNative() //on suppose en parallele
WndProc()
MonEventTouche()
MaMethodCsharp()
MaMethodNative() //on suppose en parallele
WndProc()
c'est assez logique, j'espere que c'est compréhensible.
Bref, lock/Mutex impossible (on est dans le meme thread), algo suffisement plus compliqué que ca pour que bloquer la recursivité mais prendre en compte tous les traitements soit super difficile (methode longue, fastidieuse, et avec DIFFERENTS ET BEAUCOUPS d'appels au C++, etc, etc...)
En somme, avez vous une solution pour empecher le marshaller de rappeler la WndProc (attributs sur method importée, methode pour désactiver le comportement, j'en sais rien moi, sachant qu'on doit quand meme recevoir les evenement pour bien prendre en compte le dernier)...
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 14 nov. 2007 à 15:02
bon malgré ce problème (je trouve que c'est une erreur de la part de microsoft d'avoir codé cette partie du framework comme ca), j'ai résolu le problème en gêrant cette partie de code dans une thread separé avec un event (comme un handler d'interruption de driver quoi plutot qu'une pompe à message).
Merci tout de même a ceux qui auront pris du temps pour se pencher sur mon problème (je reste malgré tout curieux de savoir s'il n'y a pas un moyen de désactiver ce comportement qui est certes pratique dans certains cas mais parfois, comme ici, fortement gênant)
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 20 nov. 2007 à 19:47
tu es sur? Alors comment explique tu ce stack overflow et ces appels récursifs? je ne vois pas d'autre possibilité (enfin le marshaller, ou autre objet/mécanisme lors des appels aux fonctions natives).
D'ailleurs pour vérifier, met un bouton dans une form et appelle une fonction native dans ce bouton (longue), tu verra que ton ihm n'est pas freezée et que si tu bourrines le bouton tu pars en stackoverflowexpcetion...En regardant letat de la stack je ne vois pas ou peut etre appelé la wndproc (surtout de cette manière récursive).
Enfin pour appeler la wndproc j'imagine qu'il doit faire un Application.DoEvents() (ou similaire)