Re: Suspend worker thread when in background

Eric Wing wrote:
> To your original problem of suspending the thread: I say don’t suspend your threads and just make them end. Design your threads so you tell them to quit and you do a wait/join.

I appreciate that in an ideal world this is preferable, but it's just not practical for me.  This is a port of an application with its roots going back 35 years and its codebase virtually unchanged for at least 15 years, and there's far too much state in the worker thread to hope to save it and then restore it again.  In any case, if my understanding is correct, there's no satisfactory way even of killing the thread asynchronously in Android so I'm no better off if in order to 'end' the thread it must poll some flag.


> many platforms can’t handle doing certain operations on the non-main thread

Tell me about it!  This caused me much grief, and taught me that initially developing an SDL app in Windows is a bad idea because it's more tolerant of this than the other platforms.  So when I thought I had a pretty much fully tested and working app, I discovered that it totally failed when ported to Linux, Mac OS, Android...


> I’d actually like to write a new alternative SDLActivity some day that keeps SDL on the main thread. This would require some changes on how people deal with
> the event loop

This sounds like a great idea, so long as it doesn't hit performance (running in a separate thread can be advantageous if it means running on a separate CPU core).  Your frustration at the shortcomings of Android are clear and understandable, but it's not going to go away and we need to try to find workarounds like this.


> So these variables remain at their previous value which can completely break your application logic.

I've read this before, but it's never affected me despite not coding defensively against it.  Whether I have simply been lucky I don't know, but I think I have seen comments to the effect that more recent versions of Android/SDL (I'm not sure which) don't suffer from this issue to the same degree.

Richard.

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