AfxBeginThread ne repond pasRésolu

Question

Bonjour,

J'ai un petit soucis avec AfxBeginThread.... l'appel de la methode ne retourne jamais.

Je ne fais rien de sp&#233;cial pourtant, je declare un objet CWinThread et
je lui associe la valuer de retour de la m&#233;thode AfxBeginThread, mais
celle ci ne rend jamais la main. Quelqu'un aurais une id&#233;e sur
l'origine possible du probleme ? Je ne trouve nul part des references &#224;
ce genre de probleme. Si vous avez des pistes &#224; me suggerer, je suis
preneur.

Merci.

Emmanuel.

ps: le code utilis&#233; est vraiment tout simple:

UINT Vme2AvsThread(LPVOID thisPointer);
void VmeDlsDll::startVmeDlsPolling(void)
{
CWinThread * m_Vme2AvsThread = AfxBeginThread( Vme2AvsThread,
  				  this ,
  THREAD_PRIORITY_HIGHEST,
  0, 
  CREATE_SUSPENDED,
  NULL );
 	ResumeThread (m_Vme2AvsThread->m_hThread );
}

UINT Vme2AvsThread(LPVOID thisPointer)
{
VmeDlsDll*  curVmeDls = (VmeDlsDll*) thisPointer;
//...//
return 0;
}

ymca2003 · Accepted Answer

Regarde le bouquin de richter s'il dit quelque chose la dessus :
http://brunews.free.fr/brunews/download/JR4.zip
http://brunews.free.fr/brunews/download/JR4Sources.zip

apparemnt il vaut mieux &#233;viter de faire des appels &#224; des fonctions situ&#233;es dans d'autre dll dans dllmain (en particulier faire des appels  aux MFC) car toutes les dll n'ont pas forc&#233;ment &#233;t&#233; charg&#233;e lors l'appel &#224; ton dllmain.

page 

"You must remember that DLLs use DllMain functions to initialize themselves. When your DllMain executes, other DLLs in the same address space probably haven't executed their DllMain functions yet. This means that they have not initialized, so you should avoid calling functions imported from other DLLs. In addition, you should avoid calls to LoadLibrary(Ex) and FreeLibrary from inside DllMain because these functions can create dependency loops. 
The Platform SDK documentation states that your DllMain should perform only simple initialization such as setting up thread local storage (discussed in [mk:@MSITStore:C:\Documents%20and%20Settings\ymorgan\Mes%20documents\Divers\Richter4.chm::/HTML/ch21a.htm Chapter 21]), creating kernel objects, and opening files. You must also avoid calls to User, Shell, ODBC, COM, RPC, and socket functions (or functions that call these functions) because their DLLs might not have initialized yet or the functions might call LoadLibrary(Ex) internally, again creating a dependency loop.


Also be aware that the same problems exist if you create global or static C++ objects because the constructor or destructor for these objects is called at the same time as your DllMain function".

ptitmanu · Answer

J'ai oubli&#233; de preciser que je demarre le Thread dans le constructeur
d'une DLL. Je ne sais pas si cela a de l'importance ou non...

bayeto · Answer

Utilise tu les fonctions d'attente (WaitForSingleObject) pour ton thread parent? Ca evite qu'il arrete prematurement ton thread enfant.

ptitmanu · Answer

Salut,

Pour repondre &#224; ta question, je n'utilise pas WaitForSingleObject. Je
ne sais pas &#224; quoi cela sert. Mais je pense que cela ne vient pas de
l&#224;, puisque c'est le thread principal qui fige... ou du moins la
methode AfxBeginThread qui ne retourne pas. 

J'ai essay&#233; plusieurs methode pour creer des threads et toutes figent
lors de la cr&#233;ation du thread lorsque la cr&#233;ation se fait pendant le
"DLL Attach Process" .... Par contre il n'y a aucun probleme lorsque je
demarre le thread par la suite.

Est ce un comportement normal pour toi ?

Je vais voir avec WaitForSingleObject, mais je n'y crois pas...enfin
n'ayant pas franchement les id&#233;es tres claires sur le mecanisme
d'initialisation des DLL, je voir.

En tout cas merci.

AfxBeginThread ne repond pas

4 réponses

Votre réponse