summaryrefslogtreecommitdiff
path: root/libs/gui/ConsumerBase.cpp
diff options
context:
space:
mode:
author Alex Vakulenko <avakulenko@google.com> 2017-03-31 18:06:19 -0700
committer Alex Vakulenko <avakulenko@google.com> 2017-04-03 16:16:22 -0700
commitf0a7bd033941e26e380232a0515e903cf8e678e5 (patch)
tree921a3d9c5783174c6674b46accc7e185aa5c8fde /libs/gui/ConsumerBase.cpp
parentb2a1ac9ee40ee4196bd6944828f04e6f3575c0ee (diff)
pdx: Rework error reporting when transfering file and channel handles
There is a lot of confusion about reporting errors when passing file and channel handles over PDX transport between client and service. Methods like Message::PushFileHandle return an integer which means both a file handle reference value (if positive) and a possible error code (if negative). But file handles could contain negative values too (when they are empty). This is used frequently when passing buffer fences around (when a fence is not being used, its fd is set to -1). This results in a special case of when PushFileHandle is called with a file handle with value of -1, the return value is actually "-errno" which becomes dependent on a global state (errno is not set by PushFileHandle itself in case file handle value is negative) and results in unpredicted behavior (sometimes errno is 0, sometimes its >0). Cleaned this all up by using Status<T> everywhere we used an int to pass value payload along with possible error code. Now the semantics of the calls are more clear. Bug: 36866492 Test: `m -j32` for sailfish-eng succeeds Ran unit tests on device (pdx_tests, libpdx_uds_tests, bufferhub_tests, buffer_hub_queue-test, buffer_hub_queue_producer-test), all pass Ran CubeSea, NativeTreasureHunt and Ithaca on Sailfish with vrflinger enabled, was able to use controller and screen rendered correctly. Change-Id: I0f40c3f356fcba8bc217d5219a0ddf9685e57fd7
Diffstat (limited to 'libs/gui/ConsumerBase.cpp')
0 files changed, 0 insertions, 0 deletions