summaryrefslogtreecommitdiffstats
path: root/chrome
diff options
context:
space:
mode:
authorviettrungluu@chromium.org <viettrungluu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2014-04-07 23:52:38 +0000
committerviettrungluu@chromium.org <viettrungluu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2014-04-07 23:52:38 +0000
commit506372bea0e3d01cec39bc1085300e3a0a3fafcc (patch)
tree59efce332f7bc646558bd8305e90cea7d1846465 /chrome
parent99f3528770c53f78b744edc9a3f0299f438fba02 (diff)
downloadchromium_src-506372bea0e3d01cec39bc1085300e3a0a3fafcc.zip
chromium_src-506372bea0e3d01cec39bc1085300e3a0a3fafcc.tar.gz
chromium_src-506372bea0e3d01cec39bc1085300e3a0a3fafcc.tar.bz2
Mojo: Dispatcher::MessageInTransitAccess functions don't need to take the lock.
It'd be safe for them to take the (Dispatcher) lock, since they're only called when they only have one ref (hence there's no lock ordering issue), but by the same token there's no need for them to take the lock at all. (Also add some comments so that I actually understand this. Maybe I'll even notice these comments the next time I notice this "issue".) R=davemoore@chromium.org Review URL: https://codereview.chromium.org/227133013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262256 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome')
0 files changed, 0 insertions, 0 deletions