Re: Suspend worker thread when in background

On 1/23/17, rtrussell <[email protected]> wrote:
>
> Eric Wing wrote:
>> Android will happily keep sucking up CPU cycles and battery on your app’s
>> background threads while backgrounded. Worst case, you can just keep
>> eating cycles.
>
> What I think I've seen happening is that the worker thread keeps running but
> the memory that it is using 'disappears', resulting in a segfault as soon as
> it attempts to access that memory.  This was not unexpected, because I
> assumed it was normal for Android to 'page out' an application's memory when
> it is in the background, and hence my desire to suspend the worker thread so
> it won't try to access it.
>
> But since you don't seem to think that leaving a worker thread running
> should be a major problem (other than wasting CPU cycles) am I wrong in my
> assumption?  What would you expect to happen to memory that the application
> has allocated (in my case using 'mmap') when it is backgrounded?
>
> Richard.
>

First, you need to make sure you are distinguishing between a
background event and a quit event (which are you getting or maybe you
are getting both).

Second, generally speaking, Android is very hands off when it comes to
the NDK side, because it is mostly oblivious to what's going on and
Google really doesn't want to be bothered writing stuff for the NDK
one way or the other. In a few respects, this works to the advantage
of the NDK developer. For example, Android imposes a Java heap size
limit on all apps. Back in 2.3-ish, it was some ridiculously small
limit like 64MB for an app, where phones may have shipped 512MB of
RAM. Games written in purely the SDK would get killed if they exceeded
64MB, which you could blow through easily with just a few large
uncompressed textures. But Android being oblivious to the NDK is
unable to enforce the Java heap size limit so you can use all the
memory that is actually available. Hence another compelling reason why
games are mostly written in using the NDK.


When Android needs more memory for another app, it will just reap your
entire process.

I don't know what Android does with mmap, if anything.

For background threads, I remember way, way back (2010-ish?), when we
were first getting OpenAL Soft and ALmixer running on Android, when
the app was backgrounded (not quit), both OpenAL Soft continued
running its mixing background thread, and ALmixer continued running
its background update loop thread. We got complaints from users (and
rightly so) that their CPU process meter apps were showing Corona
based apps eating significant CPU while backgrounded. (Remember, a lot
of users don't quit apps on Android...they just switch between apps
like on iOS.) So we had to write extra code to basically end their
threads on backgrounding. And I remember getting regression bugs or
subtle changes in behavior for some devices or OS versions in how they
traverse the application life cycle, that we might miss the background
event notification so we didn't suspend the threads (and we would get
more complaints to fix it).

-Eric
_______________________________________________
SDL mailing list
[email protected]
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org