Why mScreenReceiver in NetworkPolicyManagerService not running in its HandlerThread?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why mScreenReceiver in NetworkPolicyManagerService not running in its HandlerThread?

sharon.hou
Hi,

Does anyone know why mScreenReceiver in NetworkPolicyManagerService is not running in its HandlerThread?  Instead it is running in SystemServer server  thread.  I can see some SystemServer watchdog trigger since this receiver stuck on waiting the mRulesLock which was occasionally held by other api call. 

Do you see any impact if remove the mRulesLock from below code part?

    private BroadcastReceiver mScreenReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            synchronized (mRulesLock) {     // ANY IMPACT from  REMOVED this LOCK here ??
                // screen-related broadcasts are protected by system, no need
                // for permissions check.
                mHandler.obtainMessage(MSG_SCREEN_ON_CHANGED).sendToTarget();
            }
        }
    };

The trace:
"android.server.ServerThread" prio=5 tid=11 MONITOR
  | group="main" sCount=1 dsCount=0 obj=0x41680f00 self=0x50d3c4e8
  | sysTid=20115 nice=-2 sched=0/0 cgrp=apps handle=1326678472
  | schedstat=( 0 0 0 ) utm=552 stm=131 core=1
  at com.android.server.net.NetworkPolicyManagerService$2.onReceive(NetworkPolicyManagerService.java:~412)
  - waiting to lock <0x41a25018> (a java.lang.Object) held by tid=46 (NetworkPolicy)
  at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:757)
  at android.os.Handler.handleCallback(Handler.java:615)
  at android.os.Handler.dispatchMessage(Handler.java:92)
  at android.os.Looper.loop(Looper.java:137)
  at com.android.server.ServerThread.run(SystemServer.java:1054)

Regards
Sharon

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/bPR2kYWzHgsJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Why mScreenReceiver in NetworkPolicyManagerService not running in its HandlerThread?

Jeff Sharkey
Screen broadcasts are special since they are ordered.  If
registerReceiver() pushed them directly onto mHandler, the screen
broadcasts could be held up by other mHandler messages.  This is why
it's sending MSG_SCREEN_ON_CHANGED and allowing the broadcast to
finish quickly.

You're absolutely right that it doesn't need to acquire the lock just
to send the message; I'll submit a fix.

j

On Sun, Dec 2, 2012 at 9:43 AM, sharon.hou <[hidden email]> wrote:

> Hi,
>
> Does anyone know why mScreenReceiver in NetworkPolicyManagerService is not
> running in its HandlerThread?  Instead it is running in SystemServer server
> thread.  I can see some SystemServer watchdog trigger since this receiver
> stuck on waiting the mRulesLock which was occasionally held by other api
> call.
>
> Do you see any impact if remove the mRulesLock from below code part?
>
>     private BroadcastReceiver mScreenReceiver = new BroadcastReceiver() {
>         @Override
>         public void onReceive(Context context, Intent intent) {
>             synchronized (mRulesLock) {     // ANY IMPACT from  REMOVED this
> LOCK here ??
>                 // screen-related broadcasts are protected by system, no
> need
>                 // for permissions check.
>
> mHandler.obtainMessage(MSG_SCREEN_ON_CHANGED).sendToTarget();
>             }
>         }
>     };
>
> The trace:
> "android.server.ServerThread" prio=5 tid=11 MONITOR
>   | group="main" sCount=1 dsCount=0 obj=0x41680f00 self=0x50d3c4e8
>   | sysTid=20115 nice=-2 sched=0/0 cgrp=apps handle=1326678472
>   | schedstat=( 0 0 0 ) utm=552 stm=131 core=1
>   at
> com.android.server.net.NetworkPolicyManagerService$2.onReceive(NetworkPolicyManagerService.java:~412)
>   - waiting to lock <0x41a25018> (a java.lang.Object) held by tid=46
> (NetworkPolicy)
>   at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:757)
>   at android.os.Handler.handleCallback(Handler.java:615)
>   at android.os.Handler.dispatchMessage(Handler.java:92)
>   at android.os.Looper.loop(Looper.java:137)
>   at com.android.server.ServerThread.run(SystemServer.java:1054)
>
> Regards
> Sharon
>
> --
> You received this message because you are subscribed to the Google Groups
> "android-platform" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-platform/-/bPR2kYWzHgsJ.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=en.



--
Jeff Sharkey
[hidden email]

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

Reply | Threaded
Open this post in threaded view
|

Re: Why mScreenReceiver in NetworkPolicyManagerService not running in its HandlerThread?

sharon.hou
Got your point. Thanks for the quick update.

Sharon

On Monday, December 3, 2012 2:40:56 PM UTC-6, Jeff Sharkey wrote:
Screen broadcasts are special since they are ordered.  If
registerReceiver() pushed them directly onto mHandler, the screen
broadcasts could be held up by other mHandler messages.  This is why
it's sending MSG_SCREEN_ON_CHANGED and allowing the broadcast to
finish quickly.

You're absolutely right that it doesn't need to acquire the lock just
to send the message; I'll submit a fix.

j

On Sun, Dec 2, 2012 at 9:43 AM, sharon.hou <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="X1biSws21JgJ">sharo...@...> wrote:

> Hi,
>
> Does anyone know why mScreenReceiver in NetworkPolicyManagerService is not
> running in its HandlerThread?  Instead it is running in SystemServer server
> thread.  I can see some SystemServer watchdog trigger since this receiver
> stuck on waiting the mRulesLock which was occasionally held by other api
> call.
>
> Do you see any impact if remove the mRulesLock from below code part?
>
>     private BroadcastReceiver mScreenReceiver = new BroadcastReceiver() {
>         @Override
>         public void onReceive(Context context, Intent intent) {
>             synchronized (mRulesLock) {     // ANY IMPACT from  REMOVED this
> LOCK here ??
>                 // screen-related broadcasts are protected by system, no
> need
>                 // for permissions check.
>
> mHandler.obtainMessage(MSG_SCREEN_ON_CHANGED).sendToTarget();
>             }
>         }
>     };
>
> The trace:
> "android.server.ServerThread" prio=5 tid=11 MONITOR
>   | group="main" sCount=1 dsCount=0 obj=0x41680f00 self=0x50d3c4e8
>   | sysTid=20115 nice=-2 sched=0/0 cgrp=apps handle=1326678472
>   | schedstat=( 0 0 0 ) utm=552 stm=131 core=1
>   at
> com.android.server.net.NetworkPolicyManagerService$2.onReceive(NetworkPolicyManagerService.java:~412)
>   - waiting to lock <0x41a25018> (a java.lang.Object) held by tid=46
> (NetworkPolicy)
>   at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:757)
>   at android.os.Handler.handleCallback(Handler.java:615)
>   at android.os.Handler.dispatchMessage(Handler.java:92)
>   at android.os.Looper.loop(Looper.java:137)
>   at com.android.server.ServerThread.run(SystemServer.java:1054)
>
> Regards
> Sharon
>
> --
> You received this message because you are subscribed to the Google Groups
> "android-platform" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-platform/-/bPR2kYWzHgsJ.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="X1biSws21JgJ">android-...@googlegroups.com.
> To unsubscribe from this group, send email to
> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="X1biSws21JgJ">android-platfo...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=en.



--
Jeff Sharkey
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="X1biSws21JgJ">jsha...@...

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/1AnftTEnYb4J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.