This diagnostic rule implies that the function takes the parameter of the 'std::stop_token' type and never uses it. Such code can potentially lead to problems.
The C++20 standard introduced a new class in the standard library — 'std::jthread'. This is an alternative to the 'std::thread' class, and it has two new features. First, the 'std::jthread' object automatically joins by calling functions 'request_stop' and 'join' in the destructor. Second, the execution of a function in another thread can be interrupted via an object of the 'std::stop_token' type. Here's a synthetic example:
#include <thread> #include <vector> struct HugeStruct { .... }; HugeStruct LoadHugeData(std::string_view key); void worker(std::stop_token st, ....) { auto keys = ....; for (auto key : keys) { auto data = LoadHugeData(key); // Do something with data } } void foo() { using namespace std::literals; std::jthread thread { worker }; // .... }
The function subsequently loads large data. The implementation allows interrupting such an operation. However, the 'st' parameter is not used to receive a stop signal. Such code looks suspicious and is marked by the analyzer as a place of a potential error.
Below is an option to correct this fragment:
#include <thread> #include <vector> struct HugeStruct { .... }; HugeStruct LoadHugeData(std::string_view key); void worker(std::stop_token st, ....) { auto keys = ....; for (auto key : keys) { if (st.stop_requested()) { // Stop execution here } auto data = LoadHugeData(key); // Do something with data } } void foo() { using namespace std::literals; std::jthread thread { worker }; // .... }
Now the subsequent load can be interrupted. The 'worker' function stops loading the elements if it receives a request to cancel the operation (the 'request_stop' function) from another thread.