diff options
author | sky@chromium.org <sky@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-08 20:18:14 +0000 |
---|---|---|
committer | sky@chromium.org <sky@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-08 20:18:14 +0000 |
commit | b2134acfa36836b9ec250c02fc83f75f3a2073d7 (patch) | |
tree | 692adbba831922500a0d114bb28d6ec6540dddad /gpu/command_buffer/docs | |
parent | 6dba9b3f1164f24271916ab1bd3bdc1b50727744 (diff) | |
download | chromium_src-b2134acfa36836b9ec250c02fc83f75f3a2073d7.zip chromium_src-b2134acfa36836b9ec250c02fc83f75f3a2073d7.tar.gz chromium_src-b2134acfa36836b9ec250c02fc83f75f3a2073d7.tar.bz2 |
Revert 46757 - Fix IO thread hang on releasing a socket.
The problem was we assumed ProcessPendingRequest() would always make progress once the group's releasing socket went down to zero. However, in OnAvailableSocketSlot(), since the top stalled group might still have a releasing socket, it won't necessarily make progress. The algorithmic solution is to simply never do any socket slot processing in DoReleaseSocket() if there are any releasing sockets. This requires us to search for any stalled groups after releasing sockets gets back down to 0, so it requires the full group scan each time num_releasing_sockets goes back to 0. There is a performance hit here, but I think a linear search through 256~ groups in the worst case is ok.
TODO(willchan): evaluate the perf hit and consider adding a secondary data structure to improve the stalled group search.
BUG=42267
Review URL: http://codereview.chromium.org/2013009
TBR=willchan@chromium.org
Review URL: http://codereview.chromium.org/1992010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46792 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'gpu/command_buffer/docs')
0 files changed, 0 insertions, 0 deletions