1Vendor HAL Threading Model
2==========================
3The vendor HAL service has two threads:
41. HIDL thread: This is the main thread which processes all the incoming HIDL
5RPC's.
62. Legacy HAL event loop thread: This is the thread forked off for processing
7the legacy HAL event loop (wifi_event_loop()). This thread is used to process
8any asynchronous netlink events posted by the driver. Any asynchronous
9callbacks passed to the legacy HAL API's are invoked on this thread.
10
11Synchronization Concerns
12========================
13wifi_legacy_hal.cpp has a bunch of global "C" style functions to handle the
14legacy callbacks. Each of these "C" style function invokes a corresponding
15"std::function" version of the callback which does the actual processing.
16The variables holding these "std::function" callbacks are reset from the HIDL
17thread when they are no longer used. For example: stopGscan() will reset the
18corresponding "on_gscan_*" callback variables which were set when startGscan()
19was invoked. This is not thread safe since these callback variables are
20accesed from the legacy hal event loop thread as well.
21
22Synchronization Solution
23========================
24Adding a global lock seems to be the most trivial solution to the problem.
25a) All of the asynchronous "C" style callbacks will acquire the global lock
26before invoking the corresponding "std::function" callback variables.
27b) All of the HIDL methods will also acquire the global lock before processing
28(in hidl_return_util::validateAndCall()).
29
30Note: It's important that we only acquire the global lock for asynchronous
31callbacks, because there is no guarantee (or documentation to clarify) that the
32synchronous callbacks are invoked on the same invocation thread. If that is not
33the case in some implementation, we will end up deadlocking the system since the
34HIDL thread would have acquired the global lock which is needed by the
35synchronous callback executed on the legacy hal event loop thread.
36