`ThreadWorkerGlobalScope.callGlobalCallObjectMethod()` occasionally times out under pressure. Even if `Worker::HostOnGlobalCallInner()` calls `std::condition_variable::notify_one()`, the `std::condition_variable::wait_for()` in `Worker::GlobalCall()` never wakes up until it hits the limit of 5 seconds. The predicate is called twice, once before the wake-up attempt while still false, and the second time after the timeout when it returns true.
### 期望行为是什么?
It could be a bug in MUSL/pthread(?) but `Worker` should somehow ensure that the waiting thread doesn't miss the wakeup...
### 如何复现该缺陷
The following app creates a dozen of flashing tiles. Often, some of them stop functioning after a few seconds and the app prints "Error: GLOBAL CALL TIMED OUT, STOP!" to hilog.Notice that it could sometimes take a few tens of seconds until it happens.
`ThreadWorkerGlobalScope.callGlobalCallObjectMethod()` occasionally times out under pressure. Even if `Worker::HostOnGlobalCallInner()` calls `std::condition_variable::notify_one()`, the `std::condition_variable::wait_for()` in `Worker::GlobalCall()` never wakes up until it hits the limit of 5 seconds. The predicate is called twice, once before the wake-up attempt while still false, and the second time after the timeout when it returns true.
### 期望行为是什么?
It could be a bug in MUSL/pthread(?) but `Worker` should somehow ensure that the waiting thread doesn't miss the wakeup...
### 如何复现该缺陷
The following app creates a dozen of flashing tiles. Often, some of them stop functioning after a few seconds and the app prints "Error: GLOBAL CALL TIMED OUT, STOP!" to hilog. Notice that it could sometimes take a few tens of seconds until it happens, and reproducing the bug on more powerful hardware might require more pressure e.g. serializing an array of objects instead of numbers.