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

Reply via email to