{"id":109563,"date":"2024-03-22T07:00:00","date_gmt":"2024-03-22T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109563"},"modified":"2024-04-06T09:31:24","modified_gmt":"2024-04-06T16:31:24","slug":"20240322-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240322-00\/?p=109563","title":{"rendered":"Why does my thread get a broken string as its initial parameter?"},"content":{"rendered":"

A customer passed a string to a newly-created std::thread<\/code> but found that the std::string<\/code> received by the thread was already invalid. How can that happen?<\/p>\n

Here was how they passed the parameter to the thread:<\/p>\n

void OnWidgetChanged(const char* reason)\r\n{\r\n    std::thread backgroundThread(ProcessWidgetChange,\r\n        reason);\r\n    backgroundThread.detach();\r\n}\r\n\r\nvoid ProcessWidgetChange(std::string reason)\r\n{\r\n    \/\/ the reason is corrupted!\r\n}\r\n<\/pre>\n
The problem is that the raw const char*<\/code> pointer is being converted to a std::string<\/code> too late.<\/p>\n
To avoid confusion, let me rename the two reason<\/code> parameters:<\/p>\n
void OnWidgetChanged(const char* rawReason<\/span>)\r\n{\r\n    std::thread backgroundThread(ProcessWidgetChange,\r\n        rawReason<\/span>);\r\n    backgroundThread.detach();\r\n}\r\n\r\nvoid ProcessWidgetChange(std::string stringReason<\/span>)\r\n{\r\n    \/\/ the stringReason<\/span> is corrupted!\r\n}\r\n<\/pre>\n
The parameters to the std::thread<\/code> constructor are captured by value, and the copies are then passed to the new thread, which executes the desired code by passing those copies to std::invoke<\/code>. The specification calls out that the capturing happens  in the calling thread as part of the constructor<\/a>.<\/p>\n
Here’s a flowchart of the operations that take place:<\/p>\n\n\n\n\n\n\n\n\n\n
Original thread<\/td>\n <\/td>\n<\/tr>\n
Capture parameters by value<\/td>\n\u00a0<\/td>\n<\/tr>\n
Start new thread<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u2933<\/td>\nNew thread<\/td>\n<\/tr>\n
\u00a0<\/td>\nConvert parameters to match signature of target<\/td>\n<\/tr>\n
\u00a0<\/td>\nCall the target<\/td>\n<\/tr>\n
\u00a0<\/td>\nDestruct converted parameters<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In the above example, it means that the raw const char*<\/code> is captured and given to the thread. Only when the thread begins execution is the raw const char*<\/code> converted to a std::string<\/code>, and by that point, it’s too late.<\/p>\n\n\n\n\n\n\n\n\n\n
Original thread<\/td>\n <\/td>\n<\/tr>\n
Copy the rawReason<\/code> raw pointer<\/td>\n\u00a0<\/td>\n<\/tr>\n
Start new thread<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u2933<\/td>\nNew thread<\/td>\n<\/tr>\n
\u00a0<\/td>\nConvert: Construct stringReason<\/code> from rawReason<\/code><\/td>\n<\/tr>\n
\u00a0<\/td>\nCall the target with stringReason<\/code><\/td>\n<\/tr>\n
\u00a0<\/td>\nDestruct: Destruct stringReason<\/code> and rawReason<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The problem is clearer when the conversion is spelled out: The original code has already detached the thread and returned, at which point the caller of OnWidgetChanged<\/code> is not under any obligation to keep the pointer valid any further. The conversion to a std::string<\/code> therefore happens too late.<\/p>\n
The author of the above code was under the incorrect belief that the operations occurred in a different order:<\/p>\n\n\n\n\n\n\n\n\n\n
Original thread<\/td>\n <\/td>\n<\/tr>\n
Convert: Construct stringReason<\/code> from rawReason<\/code><\/td>\n\u00a0<\/td>\n<\/tr>\n
Capture converted parameters<\/td>\n\u00a0<\/td>\n<\/tr>\n
Start new thread<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u2933<\/td>\nNew thread<\/td>\n<\/tr>\n
\u00a0<\/td>\nCall the target<\/td>\n<\/tr>\n
\u00a0<\/td>\nDestruct: Destruct stringReason<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If you think about it, it’s not possible to do things the second way. The thread<\/code> constructor could try to infer the signature of the callable, but the callable might have multiple operator()<\/code> overloads, so the  tricks for deconstructing the function pointer<\/a> don’t work. And even if they did work, it’s possible that the caller didn’t pass the same number of parameters as the function expects, but expecting it to work because the missing parameters have default values. But there’s no way to deduce the default values (because default values are not part of the function type signature), so the converter doesn’t know what values to use for the missing parameters.<\/p>\n
The solution is to convert the rawReason<\/code> raw pointer to a std::string<\/code> while the rawReason<\/code> is still valid, pass that converted value to the std::thread<\/code> constructor.<\/p>\n
void OnWidgetChanged(const char* rawReason)\r\n{\r\n    std::thread backgroundThread(ProcessWidgetChange,\r\n        std::string(rawReason)<\/span>);\r\n    backgroundThread.detach();\r\n}\r\n\r\nvoid ProcessWidgetChange(std::string stringReason)\r\n{\r\n    \/\/ use the stringReason\r\n}\r\n<\/pre>\n
In the original customer version, the issue wasn’t about an anticipated conversion from a raw pointer to a std::string<\/code>, but rather an anticipated conversion of a raw COM pointer to a smart one:<\/p>\n
void OnWidgetChanged(IWidget* widget)\r\n{\r\n    \/\/ Oops, captures raw pointer, not ComPtr.\r\n    std::thread backgroundThread(ProcessWidgetChange,\r\n        widget);\r\n    backgroundThread.detach();\r\n}\r\n\r\nvoid ProcessWidgetChange(ComPtr<IWidget> widget)\r\n{\r\n    widget->Refresh();\r\n}\r\n<\/pre>\n
The solution, as before, is to force the conversion early:<\/p>\n
void OnWidgetChanged(IWidget* widget)\r\n{\r\n    std::thread backgroundThread(&ProcessWidgetChange,\r\n        ComPtr<IWidget>(widget)<\/span>);\r\n    backgroundThread.detach();\r\n}\r\n<\/pre>\n
Bonus chatter<\/b>: It would have been nice to use Class Template Argument Deduction (CTAD) to simplify this to<\/p>\n
void OnWidgetChanged(IWidget* widget)\r\n{\r\n    std::thread backgroundThread(&ProcessWidgetChange,\r\n        ComPtr(widget)<\/span>);\r\n    backgroundThread.detach();\r\n}\r\n<\/pre>\n
Unfortunately, as we saw earlier,  WRL’s ComPtr<\/code> doesn’t support CTAD<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
It got converted too late.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-109563","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
It got converted too late.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109563","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=109563"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109563\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=109563"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109563"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109563"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}