[jira] [Commented] (CB-3900) A blocked UI thread can result in 100s of accelerator messages banking up

["Andrew Grieve (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CB-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839248#comment-13839248 ] 

Andrew Grieve commented on CB-3900:
-----------------------------------

Solution proposed in doc: https://docs.google.com/document/d/1b2igeRoGXpdr_B89W7n2CaiXTspXq9tnrK5ocsyhNNM/edit#heading=h.bykm1gwhlrq0

> A blocked UI thread can result in 100s of accelerator messages banking up
> -------------------------------------------------------------------------
>
>                 Key: CB-3900
>                 URL: https://issues.apache.org/jira/browse/CB-3900
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: Android
>    Affects Versions: 2.7.0
>            Reporter: Peter
>            Assignee: Joe Bowser
>            Priority: Minor
>
> The OnlineEventsBridgeMode mechanism in NativeToJsMessageQueue uses *runOnUIThread* to tell some Runnable to fire and even which initiates processing of the queued messages.
> However, if the UI thread is blocked (eg user code is just sitting on an “alert”) then that Runnable will not have any chance to execute.
> Combining this case with an Accelerometer sensor (eg *getCurrentAcceleration*) and there is a possible scenario where
> * User sits on the alert, thereby blocking the UI thread for some length of time
> * The bridge message queue grows to 10s or 100s or 1000s of messages because the acceleration messages continue to be enqueued
> * 10s or 100s or even 1000s of UI runOnUIThread Runnables get queued up because the UI thread is blocked
> When the alert is finally dismissed, those (100s of?) Runnables all get a chance to run.
> While it all seems OK from the end user point-of-view, there appears to be an awful lot of (unnecessary?) work going on behind the scenes in this scenario.
> Example user code:
> {code}  navigator.accelerometer.getCurrentAcceleration(onAccelerationSuccess, onAccelerationError);
> alert('Wait here and use debugger to watch the message queue growing');
> {code}
> I don’t know if there is any viable fix for this quirk, but even if there isn’t this potential ought to be described in a comment somewhere.



--
This message was sent by Atlassian JIRA
(v6.1#6144)