Thanks for the info! The linked branch mitigates this be eliminating reconnects for twoway invocations completely, and limiting reconnection attempts for oneway invocations to at most one per second. This is an interim fix, and I'm working on a solution that will eliminate the reconnection attempts completely once they have failed a number of times, but that's a non-trivial change. For now, this will certainly help to reduce battery drain by a lot.
** Branch linked: lp:~michihenning/unity-scopes-api/reconnect-fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity-scopes-shell in Ubuntu. https://bugs.launchpad.net/bugs/1364464 Title: unity8-dash has a thread that is polling rather rapidly on epoll wait Status in “unity-scopes-api” package in Ubuntu: In Progress Status in “unity-scopes-shell” package in Ubuntu: Invalid Status in “unity8” package in Ubuntu: Invalid Bug description: one of the threads to unity8-dash is creating quite a few wakeups per second: # eventstat 60 1 Event/s PID Task Init Function Callback 13.02 2812 scopes_ng::Scop hrtimer_start_range_ns hrtimer_wakeup process 2812 is a thread of unity8-dash attaching strace to the thread we see: root@ubuntu-phablet:/proc# strace -p 2812 Process 2812 attached clock_gettime(CLOCK_MONOTONIC, {925, 47970238}) = 0 epoll_wait(57, {}, 256, 115) = 0 clock_gettime(CLOCK_MONOTONIC, {925, 165670469}) = 0 socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50 fcntl64(50, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(50, {sa_family=AF_LOCAL, sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file or directory) close(50) = 0 clock_gettime(CLOCK_MONOTONIC, {925, 174626930}) = 0 epoll_wait(57, {}, 256, 39) = 0 clock_gettime(CLOCK_MONOTONIC, {925, 215561930}) = 0 socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50 fcntl64(50, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(50, {sa_family=AF_LOCAL, sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file or directory) close(50) = 0 clock_gettime(CLOCK_MONOTONIC, {925, 222932007}) = 0 epoll_wait(57, {}, 256, 65) = 0 clock_gettime(CLOCK_MONOTONIC, {925, 290266777}) = 0 socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50 fcntl64(50, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0 ..ad infinitum... the epoll_wait() is sleeping a very short while before a connect to a clickscope named socket path is attempted over and over again. Is this rapid polling really necessary? It's contributing to 0.50%-1.00% of the CPU load of the phone. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1364464/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp