{"id":97405,"date":"2017-11-15T07:00:00","date_gmt":"2017-11-15T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=97405"},"modified":"2019-03-13T01:20:21","modified_gmt":"2019-03-13T08:20:21","slug":"20171115-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20171115-00\/?p=97405","title":{"rendered":"What happens if you simply return from the thread callback passed to _beginthread and _beginthreadex?"},"content":{"rendered":"

Medinoc asks, “What happens when one simply returns from the thread callback<\/a>? I’d suspect the code gluing between _beginthread() and its callback calls _endthread() upon return, while the code between _beginthreadex() and its callback calls _endthreadex() instead?” <\/p>\n

Yup, that’s exactly it. If your thread callback function returns, then _begin­thread<\/code> calls _end­thread<\/code> on your behalf, and then _begin­thread­ex<\/code> calls _end­thread­ex<\/code> on your behalf. The value passed to _end­thread­ex<\/code> is the return value of your thread callback function. <\/p>\n

In response to the remark “beginthread() initializes the CRT,” Cesar asked, “Which CRT<\/a>? A process can have more than one CRT, and the thread function can even call functions from several different C runtimes.” <\/p>\n

The _begin­thread<\/code> function initializes the CRT it belongs to. What other choice does it have? It’s not like msvcr80!<\/code>_beginthread<\/code> knows how to initialize the data used by msvcr90.dll<\/code>. If you call msvcr80!<\/code>_beginthread<\/code>, then the new thread is initialized for the msvcr80<\/code> runtime, since that’s the only one it knows about. <\/p>\n

If the thread function calls into multiple C runtimes, then that’s its decision. If it calls into a C runtime that hasn’t been initialized for that thread, then what happens next depends on the behavior of that C runtime. For quite some time now, Microsoft’s C runtimes are self-initializing<\/a>, meaning that the first time you call into them on a thread, they will initialize themselves on the spot. And they will also auto-uninitialize themselves when the thread exits. <\/p>\n

Wait, if the C runtime initializes itself on demand and auto-uninitializes, then why bother with _beginthread<\/code> at all? <\/p>\n

Well, the functions are still around because they predated the initialize-on-demand and auto-uninitialize behavior. And they do guarantee that the C runtime will be initialized for the new thread. (If not, then the functions return failure.) If you go for the initialize-on-demand case, and the C runtime cannot initialize itself, then something interesting happens. <\/p>\n