libbinder: setupPolling flushes commands
Calling setupPolling and then handling polled commands has the effect
of never telling the kernel anything, and then then waiting for it to
get back to you. While this type of (non)communication may be common
among some humans, it should not be common among our processes.
So - the general requirement for a flushCommands call by every client of
this call is lifted.
Critically, also, this means that LL-NDK users of the setupPolling
command don't also need a flushCommand. This avoids an extra API. Sure,
it may be useful to have such a command, but whenever it is used in our
tree, it is mostly used as a hack. So, hopefully this delay in adding it
will instead encourage fixes in libbinder which help avoid people
needing to understand binder internals.
Bug: 139697085
Test: use with servicemanager and boot
Change-Id: I45d19bf6b58950f9d91dd6f7dcaa94b8061d3666
diff --git a/libs/binder/IPCThreadState.cpp b/libs/binder/IPCThreadState.cpp
index 7d01e0b..2eee2c4 100644
--- a/libs/binder/IPCThreadState.cpp
+++ b/libs/binder/IPCThreadState.cpp
@@ -629,6 +629,7 @@
}
mOut.writeInt32(BC_ENTER_LOOPER);
+ flushCommands();
*fd = mProcess->mDriverFD;
return 0;
}