Fix bug that mpp_task is not move to cancel thread due to llvm SOO

[windtalker]

What problem does this PR solve?

Issue Number: ref #5095, close #5638

Problem Summary:

What is changed and how it works?

After #5361, in MPPTaskManager::cancelMPPQuery, we try to move mpp task to the cancel thread so each mpp task can be destructed parallelly instead of be destructed one by one in cancelMPPQuery thread.
However, due to SOO in llvm(llvm/llvm-project#32472), this move actaully failed, and there is a chance that mpp task is destructed inside the follow cancel loop:

tiflash/dbms/src/Flash/Mpp/MPPTaskManager.cpp

Lines 102 to 108 in 8404e65

	for (auto it = task_set->task_map.begin(); it != task_set->task_map.end();)
	{
	fmt_buf.fmtAppend("{} ", it->first.toString());
	auto current_task = it->second;
	it = task_set->task_map.erase(it);
	thread_manager->schedule(false, "CancelMPPTask", [task = std::move(current_task), &reason] { task->cancel(reason); });
	}

Destruct MPP inside the cancel loop means the task will be destructed before all mpp tasks are cancelled, this may cause some dead lock issues since there are some dependency between mpp tasks(especially in the case of local tunnel).

This pr fix this issue by

• Use a Functor instead of lambda as a workaround of the SOO issues
• Save the moved Functor inside a vector to make sure mpp task never be destructed inside cancel loop, even if Functor move fails due to some unknown issues.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
  run some random failpoint tests
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• gengliqi
• yibin87

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[yibin87]

Maybe, take a consideration if any exception thrown during the for loop.

[yibin87]

Others LGTM.

[windtalker]

/merge

[ti-chi-bot]

@windtalker: It seems you want to merge this PR, I will help you trigger all the tests:

/run-all-tests

You only need to trigger /merge once, and if the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

If you have any questions about the PR merge process, please refer to pr process.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 98fcda0

[windtalker]

/run-integration-test

[sre-bot]

Coverage for changed files

Filename                                         Regions    Missed Regions     Cover   Functions  Missed Functions  Executed       Lines      Missed Lines     Cover    Branches   Missed Branches     Cover
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DataStreams/CreatingSetsBlockInputStream.cpp         211                76    63.98%          11                 2    81.82%         226                68    69.91%         110                49    55.45%
Flash/Mpp/MPPTaskManager.cpp                         176               135    23.30%          18                10    44.44%         206               124    39.81%          78                57    26.92%
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                                                387               211    45.48%          29                12    58.62%         432               192    55.56%         188               106    43.62%

Coverage summary

Functions  MissedFunctions  Executed  Lines   MissedLines  Cover
18378      8366             54.48%    211602  86465        59.14%

full coverage report (for internal network access only)

[ti-chi-bot]

In response to a cherrypick label: new pull request created: #5641.

[fuzhe1989]

why not declare it as delete?

[fuzhe1989]

guess we don't actually need this vector?

[fuzhe1989]

depend on the behavior of std::function::move is risky and hard to understand.

how about this?

thread_manager->schedule(false, "CancelMPPTask", 
    [functor = new MPPTaskCancelFunctor(std::move(current_task), reason)] {
        std::unique_ptr(functor)->run(); // do not need `operator()`, just `run()`
});

IMO it's more stable than depending on some specific implementation of std::function.

[windtalker]

Good idea, since this pr is merged, I will use another pr to refine it.

[fuzhe1989]

It's actually a finally:

finally {
    thread_manager->wait();
}