Optimize dispatcher for back-to-back finished signals.

Minor tweak to the dispatcher to handle as many finished signals
in a receive callback as possible instead of going back to
the Looper and waiting for the next poll() to hit the callback
again.

This is part of a series of changes to improve input system pipelining.

Bug: 5963420

Change-Id: I8471107371693e21ce8ce7cca1e8d79ba4ca2351

Author: Jeff Brown

services/input/InputDispatcher.cpp

@@ -2043,18 +2043,30 @@ int InputDispatcher::handleReceiveCallback(int fd, int events, void* data) {
                 return 1;
             }
 
-            bool handled = false;
-            status_t status = connection->inputPublisher.receiveFinishedSignal(&handled);
-            if (!status) {
-                nsecs_t currentTime = now();
+            nsecs_t currentTime = now();
+            bool gotOne = false;
+            status_t status;
+            for (;;) {
+                bool handled = false;
+                status = connection->inputPublisher.receiveFinishedSignal(&handled);
+                if (status) {
+                    break;
+                }
                 d->finishDispatchCycleLocked(currentTime, connection, handled);
+                gotOne = true;
+            }
+            if (gotOne) {
                 d->runCommandsLockedInterruptible();
-                return 1;
+                if (status == WOULD_BLOCK) {
+                    return 1;
+                }
             }
 
-            ALOGE("channel '%s' ~ Failed to receive finished signal.  status=%d",
-                    connection->getInputChannelName(), status);
-            notify = true;
+            notify = status != DEAD_OBJECT || !connection->monitor;
+            if (notify) {
+                ALOGE("channel '%s' ~ Failed to receive finished signal.  status=%d",
+                        connection->getInputChannelName(), status);
+            }
         } else {
             // Monitor channels are never explicitly unregistered.
             // We do it automatically when the remote endpoint is closed so don't warn