You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Be explicit about RPA CoTask lifecycle; don't use thread_local
Use of thread_local CoTask to parallelize RPA indexing was added
by a recent commit: e4b01d7
The situation is fragile and there is potential for UB here due to
static initialization hell.
Instead, we explicitly create the CoTask in the DownloadBlocksTask
thread and it lives as a DownloadBlocksTask member variable, which
is more correct and less bugprone.
std::unordered_map<TxHash, unsigned, HashHasher> txHashToIndex; // since we know the size ahead of time here, we can set max_load_factor to 1.0 and avoid over-allocating the hash table
46
46
txHashToIndex.max_load_factor(1.0);
47
47
txHashToIndex.reserve(b.vtx.size());
48
-
staticthread_local std::optional<CoTask> rpaTask;
49
48
std::optional<CoTask::Future> rpaFut; // NB: rpaFut will auto-wait for work (if any) to complete as part of its d'tor
50
-
if (enableRpa) {
51
-
if (!rpaTask) {
52
-
QString threadName = Util::ThreadName::Get();
53
-
if (threadName.isEmpty()) threadName = "???"; // this should ideally not happen, but is here for defensive programming
54
-
// Create a new CoTask into TLS. It will be destructed when the current thread exits.
55
-
// The assumption here is that the DownloadBlocksTask is calling us and its threads stick around for a while
0 commit comments