Tim Armstrong has posted comments on this change. ( http://gerrit.cloudera.org:8080/9680 )
Change subject: IMPALA-6587: free buffers before ScanRange::Cancel() returns ...................................................................... Patch Set 9: (1 comment) http://gerrit.cloudera.org:8080/#/c/9680/9/be/src/runtime/io/request-context.h File be/src/runtime/io/request-context.h: http://gerrit.cloudera.org:8080/#/c/9680/9/be/src/runtime/io/request-context.h@376 PS9, Line 376: with a reference to this context. These threads do not hold : /// any locks while reading from HDFS, so we need to prevent the RequestContext from : /// being destroyed underneath them. > okay. Let's not muck with that now. I was wondering what I was missing, but Yeah I'm not really sure. It looks like there's been some variation of the logic in the I/O mgr since the start: 8c45bf6c2b7212ce274eb8b31c4f1eccd27b7ae4 I think it's accidental complexity. It seems like the requirements are: * to track which disk queue a context is already queue on (to avoid scheduling it twice). * to track how many outstanding references there are to the RequestContext is_on_queue_ is being used for both purposes. My theory is that the accidental complexity comes from this, because it means that the logical refcount is sum(is_on_queue_ + num_threads_in_op_), which complicates the bookkeeping. -- To view, visit http://gerrit.cloudera.org:8080/9680 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I87182b6bd51b5fb0b923e7e4c8d08a44e7617db2 Gerrit-Change-Number: 9680 Gerrit-PatchSet: 9 Gerrit-Owner: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-Reviewer: Bikramjeet Vig <bikramjeet....@cloudera.com> Gerrit-Reviewer: Dan Hecht <dhe...@cloudera.com> Gerrit-Reviewer: Impala Public Jenkins Gerrit-Reviewer: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-Comment-Date: Thu, 22 Mar 2018 22:52:22 +0000 Gerrit-HasComments: Yes