Thread creation, the CRT and DLL's how is it meant to be done?

Question

So I understand that CreateThread and the CRT can result in memory leaks, signal doesn't work, and one should use the _beginthread or _beginthreadex functions.

That is all very well when writing an application, but what about those that are writing dll's and such for other applications (be it a plain c dll, com objects, plugins, etc). There is no way to guarantee how a thread calling into a DLL was created, even if they used __beginthread(ex) its a pretty likely bet they have a different CRT implementation\version.

So what exactly is it that programmers are expected to do? Not use the CRT? Spawn an internal thread and offload all work to that (without using the CRT with the calling thread)? Some trick with DllMain and the attach/detach stuff to correctly setup and shutdown all threads regardless of how they are created?

Lynden

Answer 1

CreateThread and the CRT can result in memory leaks

No, that's a misunderstanding that's incredibly difficult to get rid of for some reason. Using _beginthread() was necessary back in the previous century, VS6 was the last version of VS that had a CRT that still required it.

That's been fixed, in no small part to deal with the support for the thread pool added to Windows 2000. Clearly you can't do anything in the CRT to deal with them, those threads are started by the OS itself. The implementation is pretty straight-forward. Wherever the CRT needs a thread-local variable, like the one needed by strtok(), it first checks if TLS storage was already allocated for the thread. If not, it allocates it on-the-fly.

Just use CreateThread() without fear, implicit of course with the assumption that you no longer use a 14 year old compiler.

Patently

Just came across something else. Is the "fiX" the use of the DllMain in the CRT DLL's (the thread attach/detach things), what when people insist on builds using the static crt (because dealing with a redist file is apparently too much effort for them...) – Lynden

Well, I just came across this: blog.aaronballman.com/2011/09/threading-on-windows which is an interesting read. As it turns out you're still not completely safe in the water using CreateThread with the CRT. Caution and proper understanding of what you're doing still applies. – Sorely

That's exactly the kind of half-baked blog post that makes it so hard to get rid of this myth. Look at the CRT source code to see how it uses the FlsAlloc callback to release memory when the thread terminates. – Patently

Answer 2

There are two options:

1. Do not use CRT from the DLL.
2. Ship multiple DLLs, one for every supported tool-chain version.

Where 1 is not an acceptable solution, 2 is chosen. Note that you have to ship multiple DLLs anyway, e.g. if your users compile for 32-bit and 64-bit architecture.

Callboy

Well 32/64 bit is fairly simple, and tends to be well defined. But most applications don't seem to say (e.g. what happens if being called from say .NET, or from part of Windows such as explorer.exe? And even if the installer detected and set up the correct dll, could system update not come and break it still?). Creating such things entirly without a CRT does not seem practical, is there really no way around it (perhaps an open source alternate C and C++ standard libraries that ate implemented without such issues?) – Lynden

@FireLancer: if you're talking about plugins and such, one option is to create a service in a separate EXE and let the DLL be a thin layer that communicates with the EXE. – Callboy

@FireLancer: also I wonder what functionality of the CRT you use that may cause problems..? If you write a plugin, you shall not play with the global state anyway. Other things like sprintf, std::vector, etc... will work just fine. Also according to my knowledge the memory leaks of CreateThread+CRT are somewhat outdated. Current documentation says just that "If [...], the CRT may terminate the process in low-memory conditions." As per loading two CRT versions in one process, it usually works fine. – Callboy