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