Link Copied
michaelgreen:
In CVF I createda thread for running a DLL using CreateThread. At the end of the job I returned. No apparent problems. The same setup in IVF10 caused an access violation on return. So I read up on the subject and found that I ought to use ExitThread instead of return. Now that works OK.
Huh? Frankly, I've always used RETURN, and pretty much all documentation around (C/C++ oriented though) says that it's the preferred method. I've re-tested my ThreadDlg sample, which doesn't use ExitThread, and it doesn't cause an AV. There's something fishy in your code perhaps? STDCALL (CVF default) vs. CDECL (Ifort default)?
But now I'm confused about whether I should use CreateThread/ExitThread or _beginthread/_endthread in order to avoid memory leaks. The documentation mentions that this depends on whether or not I'm using the C run-time library -well, am I? I don't know. I would really appreciate any theoretical input on this subject.
I recall having an extensive discussion on the subject a couple a years ago (found it here) but I don't think we reached a definite conclusion on anything; at least Gerry Thomas had a strong disent. You're probably safe to use _beginthread(ex), but you should be quite fine with CreateThread too (note also that entry point prototypes have to be different -- stdcall vs. cdecl !). Even if there is a memory leak, it should be so small that it's negligible unless you start creating thousands of threads (or one thread repeatedly).
I believe you may have a coding error. After CreateThread you are issuing CloseHandle on the thread handle prior to the thread termination. MSDN has"
"Closing a thread handle does not terminate the associated thread. To remove a thread object, you must terminate the thread, then close all handles to the thread."
This statement seems to imply a sequence where the CloseHandle must follow termination of the thread.
It does not, actually. You may -- and even should, even if only for the purpose of clarity -- CloseHandle as soon as you don't need it anymore (the handle, not the object it refers to), regardless if the object is still alive. A handle is just something you're given by the system to "name" the object. If you don't need to call it by name anymore, you don't need to use it and should ditch it. Thus, Mike's code structure is correct.
I know you can CloseHandleon the thread while it is active (now). However, this is contrary to the documentation (at least in the section describing CloseHandle). So one might consider this an "undocumented feature" (read matches to burn fingers with later).
No it's not. Quote from CloseHandle documentation: "Closing a thread handle does not terminate the associated thread or remove the thread object." Period. The sequel describes, in not so fortunate wording, what you need to do if you want to terminate the thread. I said that the wording is unfortunate, as it does not cover the situation when thread dies by natural death (return/ExitThread); but MSDN is not perfect.
So WaitForSingleObject at the appropriate point in the code is important.If your intention is to launch the DLL thread and let it run independently then run it as a process it its own address space.
I think you're reading too much in two words of a comment "tidy up" . True, there might be the problem where variables in use by the dll are messed up with; but we don't have enough data to conclude that. Yes, WaitFor... is often used in threading code, but there are also legitimate situations where one launches a thread and forgets about it (e.g. do you care when a thread writing output data to a slow medium such is finished, provided it has its own locking mechanism?).
