aboutsummaryrefslogtreecommitdiff
path: root/build2
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2017-03-03 16:40:38 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2017-03-03 16:40:38 +0200
commite27a91c9e3fccf52d39afb23c6dbdff117adfd5f (patch)
tree43b62ab1bed764bb838d01838a7b6b1c58ea75d7 /build2
parent139785df3aada78f8bccdda31e310733ca4d2420 (diff)
Refrain from working own queue when trying to lock target
This can easily lead to deadlock.
Diffstat (limited to 'build2')
-rw-r--r--build2/algorithm.cxx9
1 files changed, 8 insertions, 1 deletions
diff --git a/build2/algorithm.cxx b/build2/algorithm.cxx
index e44d610..51877b3 100644
--- a/build2/algorithm.cxx
+++ b/build2/algorithm.cxx
@@ -502,11 +502,18 @@ namespace build2
// to continue as soon as the lock is available in order not to nest
// things unnecessarily.
//
+ // That's what we used to do but that proved to be too deadlock-prone. For
+ // example, we may end up popping the last task which needs a lock that we
+ // are already holding. A fuzzy feeling is that we need to look for tasks
+ // (compare their task_counts?) that we can safely work on (though we will
+ // need to watch out for indirections). So perhaps it's just better to keep
+ // it simple and create a few extra threads.
+ //
target_lock l (
lock_impl (a,
ct,
task_count == nullptr
- ? optional<scheduler::work_queue> (scheduler::work_one)
+ ? optional<scheduler::work_queue> (scheduler::work_none)
: nullopt));
if (l.target == nullptr)