summaryrefslogtreecommitdiff
path: root/fastboot/device/variables.cpp
diff options
context:
space:
mode:
authorDaniel Colascione <dancol@google.com>2019-11-07 20:48:21 -0800
committerDaniel Colascione <dancol@google.com>2019-11-07 20:58:28 -0800
commit4ad4a11aa8106d98f2b78e738d88996a1fbbcd4b (patch)
treeaf3826254c66f70ae09887f1d22092bbfa99f528 /fastboot/device/variables.cpp
parent4456b5fc15c233afe3e8aedf5b87aaeed1d9e0f9 (diff)
Delay initial accept() until server initialized
When the adb client starts the adb server, it waits until the server reports that it's fully-initialized (via reply-fd) before executing its adb client operation. This wait prevent that adb client from talking to the server while it's initializing and becoming confused. But if a *different* adb client connects to the server while it's initializing, *that* client can temporarily observe unexpected state while the server initializes itself. For example, such a client can observe a device that's alive and connected as being offline while the server connects to it. The new socket activation support makes this race more apparent, since in the socket activation configuration, there's no initial adb client waiting for the server's all-clear indication and so even the first client observes the partially-initialized server state. This CL prevents the server accepting *any* client connection until the server has fully initialized itself, preventing all clients, not just the initial client, from observing a partially-initialized server. Test: test_adb.py; test_adb gtest binary Test: [with socket activation] adb kill-server; adb devices Change-Id: I5d399ee62436eee63340b6b8b0f64131ad17ac65
Diffstat (limited to 'fastboot/device/variables.cpp')
0 files changed, 0 insertions, 0 deletions