Discussion :

[vdaanen]

Bonjour a tous,

je viens a vous avec un pb qui ne me semble pas simple mais n'etant pas un expert des DLLs, j'espere me tromper ...

Voici le pb : j'ai ecrit un systeme de plugin qui se base sur les DLLs (+ ou - comme pr�sent� quelque part sur developpez.com)
Ma DLL s'appuie sur une bibloth�que-tiers compil�e en /MT (runtime link� en static) ; la DLL est egalement compil�e en /MT (je n'ai pas le choix on utilise cette option)
Cette bibloth�que-tiers d�finit une variable globale de classe C. Cette classe C fait appel, dans son contructeur a la fonction GetCurrentThreadId

Des qu'une methode de mon plugin doit utiliser un composant de cette biblioth�que-tiers, l'appli crashe.

Pour l'instant, j'ai 2 pistes :
- un "static order initialization chaos" mais comme l'erreur est repetable ca me parait suspect...
- un pb avec GetCurrentThreadId li� au fait qu'on travaille en /MT

J'ai essay� de retarder le plus possible l'utilisation d'element de cette bibloth�que-tiers de mani�re a ce que l'appli (de test pour le moment) existe
mais ca ne change rien..

Mes questions sont les suivantes:
- est-ce que la DLL peut connaitre le ThreadId de l'appli appelante avec le mode /MT. (info: Je n'ai pas cod�e de fonction DllMain)
- est-ce qu'utiliser GetCurrentThreadId est une bonne id�e dans mon contexte ? Y aurait-il une alternative pour connaitre de mani�re sure le ThreadId de l'appli qui charge une DLL ?
Je peux intervenir un peu sur cette lib mais le - possible

Toute autre question pouvant me faire voir la verit� est la bienvenue...

Vincent

[vdaanen]

au cas ou quelqu'un se retrouverait un jour dans la meme situation :
GetCurrentThreadId semble crash� lorsqu'on load une DLL avec LoadLibrary.
Ca me parait logique car au chargement, la DLL n'a probablement pas de lien (si elle doit en avoir un) avec l'executable qui l'a charg�e.

donc il faut mieux eviter d'utiliser cette fonction dans l'init d'une DLL

enfin, ce n'est que le retour de ma toute pitite experience avec les DLLs...

V