Alexey Serbin has posted comments on this change. Change subject: threadpool: token-based task sequencing ......................................................................
Patch Set 4: (11 comments) http://gerrit.cloudera.org:8080/#/c/6874/4//COMMIT_MSG Commit Message: Line 7: threadpool: token-based task sequencing nit: consider keeping length of lines under 72 chars: https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines PS4, Line 10: m nit: would it be better for readability if this letter were capital? PS4, Line 10: n ditto http://gerrit.cloudera.org:8080/#/c/6874/4/src/kudu/util/threadpool-test.cc File src/kudu/util/threadpool-test.cc: PS4, Line 563: for (auto& t : tokens) { : t.Wait(); : } What happens if an assertion fires above? Is it necessary to wait for tokens or destroying them without wait would be fine? http://gerrit.cloudera.org:8080/#/c/6874/4/src/kudu/util/threadpool.cc File src/kudu/util/threadpool.cc: PS4, Line 328: SequenceToken ThreadPool::AllocateTokenSlot() { Is there a restriction on maximum number of allocated token slots? PS4, Line 345: unique_ptr<SequenceSlot> new_slot(new SequenceSlot(&lock_)); : DCHECK_EQ(SequenceSlot::DEALLOCATED, new_slot->state()); : slots_.emplace_back(std::move(new_slot)); : idx = slots_.size() - 1; : } : : slots_[idx]->Transition(SequenceSlot::INACTIVE); Regarding this transition from DEALLOCATED to INACTIVE for non-existing slot: why is it necessary? I see the transition signals other actors calling Wait() for WaitFor(), but why would those guys be interested in receiving a notification that a new token slot has been allocated while waiting on some other slots? I might be missing something here, but would it be feasible setting the state of a newly allocated slot to INACTIVE, not DEALLOCATED? http://gerrit.cloudera.org:8080/#/c/6874/4/src/kudu/util/threadpool.h File src/kudu/util/threadpool.h: PS4, Line 21: #include <list> nit: not sure this is needed PS4, Line 24: #include <unordered_map> nit: not sure this is needed PS4, Line 157: binded nit: bound? PS4, Line 182: int nit: why not to use the newly introduced typedef here as well (and re-order the typedef and this declaration)? PS4, Line 182: kInvalidSlotIndex nit: since it's an integral type and we are using C++11, consider defining the value of this static variable right here in the header. -- To view, visit http://gerrit.cloudera.org:8080/6874 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: If46dc34212027b6ea5dbc2ead7c7af8be57f2c70 Gerrit-PatchSet: 4 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Dan Burkert <danburk...@apache.org> Gerrit-Reviewer: David Ribeiro Alves <davidral...@gmail.com> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
