Thread: AfxBeginThead leaking or not...

Hi,

Suppose you are creating a simple multithreaded application in MS visual C/C++ (ver.6), Now please consider the following cases:

CASE 1:
------------

A Non-MFC application, where the Thread Function calls one or more C Run-time functions.
According to documentation we should use C Run-time function _beginthread , instead of directly calling WIN API Thread functions, to prevent memory leak. Fine.

CASE 2:
------------

The same application now MFC. Thread Function calls one or more C Run-time functions, so don’t use WIN API directly. Documentation also says don’t use _beginthread on MFC, use AfxBeginThread.

Hmm! Isn’t AfxBeginThread is just a wrapper for the CreateThread API function. Does it take care about those memory leak ( calling C Run-times in Thread function, remember) ?

Oh! I’m surely missing something here. What do you guys think?

AfxBeginThread doesn't call CreateThread(), it calls CWinThread::CreateThread(). I'm guessing the implementation is different, and without memory leaks.

As Doug mentioned, CWinThread uses _beginthreadex() under the hood. As for the memory leak, allow me to regurgitate a previous posting of my own:

***
The memory which is potentially leaked, comes from a per-thread structure that is allocated off the heap. In order to understand when the leak occurs, we need to know (a) when the structure is allocated, and (b) when the structure is free'd.

When is it allocated?

• When _beginthread[ex] is called.
• When any CRT function is called that creates the global structure (so it can be used).

When is it free'd?

• When _endthread[ex] is called.
• When _beginthread[ex] is used, _endthread[ex] is called for you auto-magically.
• When linked to the CRT dynamically, the structure is free'd auto-magically.

When is memory leaked?

• When linking statically with the CRT -> and CreateThread() is used -> and the thread calls a CRT function that allocates the global structure -> and the thread does not call _endthread[ex].
• When a DLL module calls DisableThreadLibraryCalls() -> then satisfies the first bullet.

gg