Bug: UIKit (iOS) version should NOT be calling Pump Events (iOS Multitasking related)

SDL Development
1

While we are back on this subject, here’s a problem that hopefully we
can work around.

If we get in the callback mechanism, the biggest problem with it is the
callbacks can interrupt your code at bizarre times. If it’s not
predictable, it’s nearly impossible to deal with.

The only time you can get a callback is if you give up control to a OS
level API, and I think (it’s so very hard to track this and I’m not
getting any answers in the cocoa list) it only happens when you hit the
CFRunLoopRunInMode in SDL_uikitevents.m. This makes sense, but I
can’t prove it conclusively.

My pseudo code loop is like this:

while (game on)
{
check events
if (suspened) continue;

do game stuff
draw
swap buffer
other stuff
}

got_will_resign
{
suspend=true
}

The problem? I get suspend OUTSIDE of “check events”. Therefore, I
could be attempting to save state (the enter background comes right
after the resign) and then when it re-enters the foreground, it’ll start
in a bizarre place and probably crash.

The reason (again, I think) is that pump events is being invisibly
called inside SDL. The big one is in UIKit_GL_SwapWindow in
SDL_uikitopengles.m. This is killing me, I had to comment it out to get
everything to work.

The remark says “we need to let the event cycle run, or the OS won’t
update the OpenGL view!” This doesn’t necessary seem true, but I’m
already running the event cycle so it’s hard to tell.

Is it possible we could get a flag to turn this off, or just remove it,
and if it’s necessary, just put up a note in the docs that people need
to pump events on their own?

Also, what else could call pump events (polling events is obviously OK.)

[>] Brian

2

I think you’re on to something here - we should figure out exactly what circumstances can cause a callback, and it may be perfectly reasonable to handle it as an event if we can conclusively show that
only PumpEvents produces the callbacks.

However as a hypothetical - can we get a low memory callback when issuing malloc?On 03/22/2012 06:22 AM, Brian Barnes wrote:

While we are back on this subject, here’s a problem that hopefully we can work around.

If we get in the callback mechanism, the biggest problem with it is the callbacks can interrupt your code at bizarre times. If it’s not predictable, it’s nearly impossible to deal with.

The only time you can get a callback is if you give up control to a OS level API, and I think (it’s so very hard to track this and I’m not getting any answers in the cocoa list) it only happens
when you hit the CFRunLoopRunInMode in SDL_uikitevents.m. This makes sense, but I can’t prove it conclusively.

My pseudo code loop is like this:

while (game on)
{
check events
if (suspened) continue;

do game stuff
draw
swap buffer
other stuff
}

got_will_resign
{
suspend=true
}

The problem? I get suspend OUTSIDE of “check events”. Therefore, I could be attempting to save state (the enter background comes right after the resign) and then when it re-enters the foreground,
it’ll start in a bizarre place and probably crash.

The reason (again, I think) is that pump events is being invisibly called inside SDL. The big one is in UIKit_GL_SwapWindow in SDL_uikitopengles.m. This is killing me, I had to comment it out to get
everything to work.

The remark says “we need to let the event cycle run, or the OS won’t update the OpenGL view!” This doesn’t necessary seem true, but I’m already running the event cycle so it’s hard to tell.

Is it possible we could get a flag to turn this off, or just remove it, and if it’s necessary, just put up a note in the docs that people need to pump events on their own?

Also, what else could call pump events (polling events is obviously OK.)

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

3

Piotr’s solution (which is already a patch which he says he’ll release a
new version) handles all this, so I say we go with it. Making ALL the
events callbacks would be ill advised (IMHO).

The fact remains that this is going to end up being VERY OS specific.
There’s no ifs, ands, or buts, and therefore the solution is going to
end up being some specific callback IDs.

Piotr, maybe you should make sure to put iOS or something similiar in
your callback #define IDs as some will end up being specific, and
Android (or something) in your android ones (I don’t know enough about
this to comment) – unless you already did! :slight_smile:

I see, to get everything in iOS up-to-date, we need two things:

  1. Piotr’s newest patch
  2. Removal of any invisible pump events in the uikit sources

Everything else can work as it has before. THIS is important as the
whole point of SDL is so you don’t have to write a lot of platform
specific code. This is just a case where there’s no way around it.

[>] Brian

4

Message-ID: <4F6A43B0.8070303 at ghdigital.com>
Content-Type: text/plain; charset=ISO-8859-1

I don’t think that behavior would be considered appropriate on iOS or
Android, users would complain that they just switched away to check their
email and go back and it’s back to a checkpoint much
earlier.

The saving of exact current state is an expected feature.

A good example would be a game with checkpoints while progressing
through it. In this case there is no need to save the state of the game
between checkpoints, because it was already saved at a checkpoint. When
such game is terminated and ran again the progress starts from the last
saved checkpoint.

regards,
Piotr

Message-ID: <4F6B24F1.1090302 at charter.net>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

Piotr wrote:

Don’t do that! If I’m playing your game, and I’m halfway to the next
checkpoint, and I get a phone call, I don’t want to get back to the game
and find out I’ve lost a couple minutes of progress! That’s the easiest
way to get a lot of 2 star reviews :slight_smile:

BTW, thanks for the work on the patch. Hopefully we can convince the
powers that be to put it in the repo.

[>] Brian

A good example would be a game with checkpoints while progressing
through it. In this case there is no need to save the state of the game
between checkpoints, because it was already saved at a checkpoint. When
such game is terminated and ran again the progress starts from the last
saved checkpoint.

A pure check-point system may normally be a bad idea (exception:
Minesweeper; slow-enough state change that you could justify using
each click that changes something as a checkpoint), but it could
potentially make it quicker to save your state, since you would only
need to save the changes instead of the entirety of the current level.> Date: Wed, 21 Mar 2012 14:10:08 -0700

From: Forest Hale
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS MultiTasking and CallBacks
On 03/21/2012 11:16 AM, sdl at union.pl wrote:
Date: Thu, 22 Mar 2012 09:11:13 -0400
From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: Re: [SDL] iOS MultiTasking and CallBacks

Date: Thu, 22 Mar 2012 09:22:34 -0400
From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: [SDL] Bug: UIKit (iOS) version should NOT be calling Pump
Events (iOS Multitasking related)
Message-ID: <4F6B279A.1090409 at charter.net>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

While we are back on this subject, here’s a problem that hopefully we
can work around.

If we get in the callback mechanism, the biggest problem with it is the
callbacks can interrupt your code at bizarre times. If it’s not
predictable, it’s nearly impossible to deal with.

The only time you can get a callback is if you give up control to a OS
level API, and I think (it’s so very hard to track this and I’m not
getting any answers in the cocoa list) it only happens when you hit the
CFRunLoopRunInMode in SDL_uikitevents.m. This makes sense, but I
can’t prove it conclusively.

It’s worth noting that any OS which has preemptive multi-threading
could potentially stomp all over your callback prediction by pushing
the call to the callback directly onto the stack before giving the
processor back to your program’s registered callback location, instead
of giving it back to the location that was executing when the thread
was preempted (yes, OSes that want to CAN actually do this with modern
hardware). You’d wind up with the location of the callbacks being
essentially completely unpredictable, due to the fact that they get
issued in response to outside events, during time that your program
doesn’t experience.

Not that I’m saying that iOS currently does this (in fact, I don’t
think it’s very common at all outside of *nix signal handlers, &
low-level hardware stuff), but the ability to archive your run-state
for later restoration (app-level persistence, essentially) really is
what Apple seems to be expecting, and they could change their
implementation without warning. Also, you could probably use most of
the same code for/from game-saves, so you’ll be doing much of the same
work regardless.

Date: Thu, 22 Mar 2012 06:26:21 -0700
From: Forest Hale
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Bug: UIKit (iOS) version should NOT be calling Pump
Events (iOS Multitasking related)
Message-ID: <4F6B287D.5080805 at ghdigital.com>
Content-Type: text/plain; charset=ISO-8859-1

I think you’re on to something here - we should figure out exactly what
circumstances can cause a callback, and it may be perfectly reasonable to
handle it as an event if we can conclusively show that
only PumpEvents produces the callbacks.

Creating an event that the app can use to display some info to the
user might be a good reason to issue events for callbacks, but the OS
will probably be expecting a response from that callback, so
automatically longjumping out of the callback is a really bad idea.

Date: Thu, 22 Mar 2012 12:09:38 -0300
From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] Bug: UIKit (iOS) version should NOT be calling Pump
Message-ID:
<CAKDfesmNGhA6CirKjkFtozxP64zMc5xx+WmDvnUALD44boubow at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

2012/3/22 Brian Barnes

Assumptions I’m making:

  • A SDL iOS app is fundamentally single threaded.

Not necassarily.

  • By the mere fact of being single threaded, callbacks will only happen at
    some point when you relinquish control to the iOS system (as it seems to be
    the case from what you said)

I believe that to be the case with the current versions of iOS, but
Apple can (quite happily) change that in some future version, breaking
anything that depends on it. Look up preemptive multithreading, and
think a bit about how the preemption works, and how much access the
memory manager can allow the OS to have over a thread’s memory while
it isn’t running.

In essence, a standardized way to hook into these callbacks from SDL
really is the correct way to deal with them. It could also apply to
signals on *nix systems, though I don’t think anyone’s worried about
it there.