WDForge.org - Forums - WD 9 - Thread bloquant... Bizarre

Index des forums WDForge.org

WD 9

Thread bloquant... Bizarre

Bas

Suivant S'enregistrer pour contribuer

Thread bloquant... Bizarre

Utilisateur WDF

Inscrit:
28/06/2005 15:02

De Aurillac Cantal Auvergne

Post(s): 91

Tout d'abord, bonjour à tous !

Dans le cadre du développement d'une application dans mon stage, il faut que je gère l'écoute d'évènements windows. La fonction Evènement ne gère que les messages envoyés à une fenêtre, ce qui ne correspond pas. Je me suis donc inspiré du code d'un exemple en C fourni avec la dll qui envoie ces évènements. Donc pour bien faire, il faut que je lance un thread qui :

-crée 3 évènements ayant pour noms respectifs les noms des évènements envoyés par la dll;
-attend le changement d'état de ces évènements.

En l'occurence, je crée un 4e évènement, qui est là pour court-circuiter l'écoute, afin de quitter l'appli.

Le code est le suivant :

PROCEDURE gpSabreApiEcouteEvts

hndEvent est une chaîne
waitRet est un entier = 0
ret est un entier = 0

hndEvent = API("Kernel32.dll", "CreateEventA", Null, Faux, Faux, "MYSABRE_API_READY")
SI hndEvent <> Null ALORS
	gntHndEvents[1] = Val(hndEvent)
SINON
	Info("Impossible de créer l'évènement MYSABRE_API_READY")
FIN

hndEvent = API("Kernel32.dll", "CreateEventA", Null, Faux, Faux, "MYSABRE_API_RELEASE")
SI hndEvent <> Null ALORS
	gntHndEvents[2] = Val(hndEvent)
SINON
	Info("Impossible de créer l'évènement MYSABRE_API_RELEASE")
FIN

hndEvent = API("Kernel32.dll", "CreateEventA", Null, Faux, Faux, "MYSABRE_API_RESUME")
SI hndEvent <> Null ALORS
	gntHndEvents[3] = Val(hndEvent)
SINON
	Info("Impossible de créer l'évènement MYSABRE_API_RESUME")
FIN

hndEvent = API("Kernel32.dll", "CreateEventA", Null, Faux, Faux, "STOP_THIS")
SI hndEvent <> Null ALORS
	gntHndEvents[4] = Val(hndEvent)
SINON
	Info("Impossible de créer l'évènement STOP THIS")
FIN

TANTQUE PAS gbArreteEcoute
	waitRet = Val(API("kernel32.dll", "WaitForMultipleObjects", 4, &gntHndEvents, Faux, -1))
	SI WAIT_OBJECT_O <= waitRet <= WAIT_OBJECT_O + 3 ALORS
		SELON (waitRet - WAIT_OBJECT_O + 1)
			CAS 1
				gnEtatMySabreEmu = 2
				SI PAS gbLanceMySabreAuto ALORS
					gSabreApiConnecte()
				FIN
			CAS 2
				PostMessage(Handle(gsFenetreAppelante), "RELEASE", 0, 0)
			CAS 3
				PostMessage(Handle(gsFenetreAppelante), "RESUME", 0, 0)
			CAS 4
				gbArreteEcoute = Vrai
		FIN
	FIN
FIN

gbArreteEcoute = Faux

Cette procédure est exécutée dans un thread lancé comme ceci :

ThreadExécute("thrGereEvts", threadNormal, gpSabreApiEcouteEvts)

Le thread est exécuté dans le code d'initialisation du projet.

Seulement voilà, l'exécution du thread est bloquant pour l'application, cad il s'exécute comme si c'était une procédure standard, et l'application ne continue pas à se charger.

En rusant un peu, ça marche :

TANTQUE PAS gbArreteEcoute
	waitRet = Val(API("kernel32.dll", "WaitForMultipleObjects", 4, &gntHndEvents, Faux, 10))
	SI WAIT_OBJECT_O <= waitRet <= WAIT_OBJECT_O + 3 ALORS
		SELON (waitRet - WAIT_OBJECT_O + 1)
			CAS 1
				gnEtatMySabreEmu = 2
				SI PAS gbLanceMySabreAuto ALORS
					gSabreApiConnecte()
				FIN
			CAS 2
				PostMessage(Handle(gsFenetreAppelante), "RELEASE", 0, 0)
			CAS 3
				PostMessage(Handle(gsFenetreAppelante), "RESUME", 0, 0)
			CAS 4
				gbArreteEcoute = Vrai
		FIN
	FIN
     Multitâche(-50)
FIN

Le problème, c'est que comme ça, l'écoute d'évènements n'est pas permanente. On ne risque pas de les rater mais bon, c'est quand même pas très propre. De plus, l'application dans laquelle l'écoute doit être intégrée contient des traîtements assez lourds, et ça les ralentit énormément.

Je vous avoue que je reste pantois devant ce problème. J'ai contacté le ST par téléphone, mais ils ne savent pas m'en dire plus (adressez-vous à l'assistance directe.. hum hum...).

Si quelqu'un a une idée concernant ce problème, je suis preneur :)

Merci à vous !

Contribution le : 17/01/2006 11:57

_________________
La touche F1 est et restera toujours ta meilleure amie :p

	Re: Thread bloquant... Bizarre	#2
Animateur WDF Inscrit: 19/01/2004 13:48 De www.sigmasys.fr Post(s): 988	Bonjour, il faudrait essayer avec un multitâche(-1). Celà devrait marcher :) Bon dév., Totof Contribution le : 17/01/2006 13:50
	_________________ [ Totof(Christophe LOGEL) réalise des développements spécifiques WinDev (Mon annonce wdforge), http://www.sigmasys.fr]

	Re: Thread bloquant... Bizarre	#3
AJ	Un truc du genre: TANTQUE ThreadEtat("thrGereEvts")<>threadInexistant Multitâche(36000) FIN te prendra moins de ressources qu'un multitache(-1) Contribution le : 17/01/2006 21:21
AJ

	Re: Thread bloquant... Bizarre	#4
Animateur WDF Inscrit: 19/01/2004 13:48 De www.sigmasys.fr Post(s): 988	Citation : AJ a écrit: TANTQUE ThreadEtat("thrGereEvts")<>threadInexistant Multitâche(36000) FIN C'est vraiment n'importe quoi de proposer des solutions comme ca ! De plus pour ca il existe l'instruction ThreadAttend qui prend encore moins de ressource. Avant de répondre n'importe quoi, on lit les posts en entier merci. P.S. pour BofKill : Il vaut mieux lancer tes threads depuis une fênetre au lieu du code d'initialisation du projet. J'avais fait une appli industrielle qui utilisait plus de 25 threads en parallèle pas de soucis niveau perf. vive le multitache(-1) ! Pourquoi faire un WaitForMultipleObjects avec un délai d'attente de 10 ms pourquoi ne pas faire un délai d'attente infini du coup plus de problème ? Bon dév., Totof Contribution le : 18/01/2006 00:06
	_________________ [ Totof(Christophe LOGEL) réalise des développements spécifiques WinDev (Mon annonce wdforge), http://www.sigmasys.fr]

	Re: Thread bloquant... Bizarre	#5
AJ	1) Merci de ta non cordialité 2) C'est peut être pas une très bonne solution, mais franchement tu vas pas me faire croire que ton Multitache(-1) ne pompe pas de ressources pour rien... il n'ya qu'à le tester ou voir le forum PCSoft... Contribution le : 18/01/2006 10:49
AJ

	Re: Thread bloquant... Bizarre	#6
Animateur WDF Inscrit: 19/01/2004 13:48 De www.sigmasys.fr Post(s): 988	Bonjour AJ, Explication plus "cordiale" (car d'habitude je suis cordial mais bon ...) : Pour toi qu'est ce qui est le plus important : "Bouffer des resources pour rien" ou "Avoir une application rapide qui répond au quart de tour" ? N'empêche que dans le cas de bofkill, son thread prend 0% de ressources système tant que la condition suivante n'est pas vérifiée: `API("kernel32.dll", "WaitForMultipleObjects", 4, &gntHndEvents, Faux, -1)` Car le WaitForMultipleObjects est bloquant au niveau du thread, donc la boucle est stoppée. Le seul soucis c'est que dans le code d'initialisation du projet ce thread bloque son appli d'où l'intérêt de le lancer à partir d'une fenêtre (la première du projet par exemple ). Le multitâche(-1) permet d'éviter de bloquer l'application pendant le laps de temps infime de retour au début de la boucle. CQFD et sans rancune Bon dév., Totof Contribution le : 18/01/2006 11:21
	_________________ [ Totof(Christophe LOGEL) réalise des développements spécifiques WinDev (Mon annonce wdforge), http://www.sigmasys.fr]

	Re: Thread bloquant... Bizarre	#7
Inscrit: 19/11/2002 12:20 Post(s): 390	Humm, les fonctions "multitache" sont à BANNIR des threads, si vous voulez que votre soft fasse porte nawak, plante et plus si affinités, utilisez multitache ;) Pour le remplacer (si besoin) un ThreadAttendSignal (1) suffit largement... D'autre part, un WaitForMultipleObject en boucle, c'est pas très très très très chrétien :D Comme Totof, j'ai fait pas mal de softs fonctionnant avec des threads (watch de ports séries, serveur TCP IP etc...) et il n'y a pas de soucis à signaler si on respecte un ou deux trucs :) Pour le coup des event, vous êtes sûr qu'il faut que l'event attaque la fenêtre Windev? Je me souviens que je pouvais capter / intercepter les events Windows disant quand le lecteur CD était ouvert / fermé avec la fonction événement (faire joujou avec les "*"). Avez vous essayé de changer la priorité du thread par ThreadPriorité pour le mettre en priorité basse? Autre chose à checker et que j'avait signalé au ST il y a un moment (pas retesté depuis), lorsqu'on faisait un appelldll32 ou un API() dans un thread, c'était bloquant pour le thread (ça c'est normal) MAIS aussi pour TOUTE l'application... A checker donc si ce comportement a été résolu depuis... Ceci étant dit, il faudrait aussi essayer en créant une fenêtre, même invisible, histoire de voir ça peut servir des fois :) Contribution le : 18/01/2006 11:32
Inscrit: 19/11/2002 12:20 Post(s): 390

	Re: Thread bloquant... Bizarre	#8
Animateur WDF Inscrit: 19/01/2004 13:48 De www.sigmasys.fr Post(s): 988	Perso, je n'ai jamais eut de soucis avec le multitache dans les threads (mais ThreadAttendSignal pourrait aussi faire l'affaire c'est vrai), il suffit de ne pas avoir de conflits inter-thread et ca roule, et pour les appels de fonction API dans les threads celà ne m'a jamais bloqué l'application entière (surement parce que je lancais les threads depuis une fenêtre en back screen). Bon dév., Totof Contribution le : 18/01/2006 12:05
	_________________ [ Totof(Christophe LOGEL) réalise des développements spécifiques WinDev (Mon annonce wdforge), http://www.sigmasys.fr]

Haut

S'enregistrer pour contribuer

Vous ne pouvez pas débuter de nouveaux sujets.

Vous pouvez voir les sujets.

Vous ne pouvez pas répondre aux contributions.

Vous ne pouvez pas éditer vos contributions.

Vous ne pouvez pas effacez vos contributions.

Vous ne pouvez pas ajouter de nouveaux sondages.

Vous ne pouvez pas voter en sondage.

Vous ne pouvez pas attacher des fichiers à vos contributions.

Vous ne pouvez pas poster sans approbation.