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

SDL Development
1

Ugh, I’ve found some postings that say you CAN get the low memory
warning in a foreground app, but it’s more than likely you that’s
causing it, and what would be the solution?

As I was saying in the earlier message, iOS does some stuff during low
memory you might not want to deal with, like unloading any nibs and view
controllers and such.

It’s still not reasonable to handle in an event; for one, if you need
more than 5 seconds to save state, that can only be handled in the
callback itself (again, as far as I can read in the docs.)

Also, and here’s the killer, without callbacks you can’t respond to low
memory or kill properly (you have no CPU time, you can’t call pump events.)

iOS, by design, expects you to do this stuff in a callback. Can you get
away with an event? Probably, but it’ll be in the realm of a hack and
you are asking for future problems in new iOS versions and possible
rejections.

[>] Brian

Forest Hale wrote:> 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?

2

I looked at this briefly a while back and came to the same conclusion.
More specifically, if you’re handling things with events it means that
there is a period of execution between when the event is created and
when you handle it.

Anything can happen in the intervening time, including things that
you’re not allowed to do that can easily crash the whole app. The SDL
event model isn’t really compatible with how iOS expects things to be
handled.On 22/03/2012 13:54, Brian Barnes wrote:

iOS, by design, expects you to do this stuff in a callback. Can you get
away with an event? Probably, but it’ll be in the realm of a hack and
you are asking for future problems in new iOS versions and possible
rejections.

3

My own setup is simply a hack, were I receive the callbacks and respond
immediately, I’m ignorant of the architecture, but recall readying about
how the callbacks are synchronous and run on the main thread. I assume that
SDL hijacks said thread and so stays single threaded, therefore I don’t
deal with any concurrency issues.

So I receive said callbacks (and you MUST be able to respond to low memory
ones, unless your app has a completely static memory map, for instance I
unload music and delete pather and AI caches), and react right then and
there. I don’t see any way in which to shoehorn SDL’s event system to the
iOS system in a way which guarantees the systems intentions are
communicated clearly, so I vote for a really simple extension to SDL,
whereby you register a listener, and when such an event is triggered, the
listener immediately receives the event and handles it as best it can. It’s
not (IMHO) in SDL’s scope to to massage any such system callbacks into
something that they aren’t, especially since we’re talking about a system
specific behaviour. Let the dev respond as best they can!

For example, Cocoa allows you to spawn background threads that run even
while your app is suspended, these are designed for the very problems this
thread is discussing. However, it’s not SDL’s responsibility to present
this in it’s API. If you’re writing for iOS, you can integrate this (or
not) into your app in a way that is best suited to your needs! Yes, there
are some best practices such as stopping rendering (a must), and unloading
textures, saving state, but SDL is not responsible for enabling those, devs
can do that on their own using the best API at hand.

In conclusion, simple listener callbacks please.On Thu, Mar 22, 2012 at 10:03 AM, Tim Angus wrote:

On 22/03/2012 13:54, Brian Barnes wrote:

iOS, by design, expects you to do this stuff in a callback. Can you get
away with an event? Probably, but it’ll be in the realm of a hack and
you are asking for future problems in new iOS versions and possible
rejections.

I looked at this briefly a while back and came to the same conclusion.
More specifically, if you’re handling things with events it means that
there is a period of execution between when the event is created and when
you handle it.

Anything can happen in the intervening time, including things that you’re
not allowed to do that can easily crash the whole app. The SDL event model
isn’t really compatible with how iOS expects things to be handled.

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

4

2012/3/22 Brian Barnes

Ugh, I’ve found some postings that say you CAN get the low memory warning
in a foreground app, but it’s more than likely you that’s causing it, and
what would be the solution?

As I was saying in the earlier message, iOS does some stuff during low
memory you might not want to deal with, like unloading any nibs and view
controllers and such.

It’s still not reasonable to handle in an event; for one, if you need more
than 5 seconds to save state, that can only be handled in the callback
itself (again, as far as I can read in the docs.)

Also, and here’s the killer, without callbacks you can’t respond to low
memory or kill properly (you have no CPU time, you can’t call pump events.)

iOS, by design, expects you to do this stuff in a callback. Can you get
away with an event? Probably, but it’ll be in the realm of a hack and you
are asking for future problems in new iOS versions and possible rejections.

I’m throwing this out as an idea/suggestion as the discussion is
interesting to me, but be aware my comments are sprinkled with heavy doses
of ignorance!

Assumptions I’m making:

  • A SDL iOS app is fundamentally single threaded.
  • 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)
  • Objective-C supports exceptions and they are usable in this context

If all of the above is true, can a solution like this one potentially work?

Your event loop ->
Call PollEvent ->
PollEvent sets up a try catch, inside of it calls CFRunLoopRunInMode ? ->
the call takes its route inside iOS plumbing, eventually a callback is
generated ->
the SDL handler for the callback raises an exception ->
back now to PollEvent (if iOS doesn’t catch exceptions in the callbacks),
which catches the exception, returns a “high priority” event (SDL_LOWMEM
for example)
app gets that event, handles it

If exceptions are not an option, could a similar set up be accomplished
with setjmp/longjmp as it’s already being done in UIKit_PumpEvents ?

Another more general idea, is adding a SDL_RegisterEventHandler sort of
function, which if used will put SDL in a “event driven” mode (useful for
iOS, NaCl, perhaps others), where you don’t have to pump events.–
Gabriel.

5

I think the first assumes a bit too much about how the system will generate
those events. Besides that, setjmp and longjmp don’t play well with C++
stack unwinding, which would lead to a lot of memory leakage. The second is
what I’ve been voting for from the beginning. I think that in the case of
system specific events the library should interfere as little as possible
and offer a way to propagate them to the client as immediately as possible.
Let the client handle it in the way most suitable to their app.On Thu, Mar 22, 2012 at 11:09 AM, Gabriel Jacobo wrote:

2012/3/22 Brian Barnes

Ugh, I’ve found some postings that say you CAN get the low memory warning
in a foreground app, but it’s more than likely you that’s causing it, and
what would be the solution?

As I was saying in the earlier message, iOS does some stuff during low
memory you might not want to deal with, like unloading any nibs and view
controllers and such.

It’s still not reasonable to handle in an event; for one, if you need
more than 5 seconds to save state, that can only be handled in the callback
itself (again, as far as I can read in the docs.)

Also, and here’s the killer, without callbacks you can’t respond to low
memory or kill properly (you have no CPU time, you can’t call pump events.)

iOS, by design, expects you to do this stuff in a callback. Can you get
away with an event? Probably, but it’ll be in the realm of a hack and you
are asking for future problems in new iOS versions and possible rejections.

I’m throwing this out as an idea/suggestion as the discussion is
interesting to me, but be aware my comments are sprinkled with heavy doses
of ignorance!

Assumptions I’m making:

  • A SDL iOS app is fundamentally single threaded.
  • 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)
  • Objective-C supports exceptions and they are usable in this context

If all of the above is true, can a solution like this one potentially work?

Your event loop ->
Call PollEvent ->
PollEvent sets up a try catch, inside of it calls CFRunLoopRunInMode ? ->
the call takes its route inside iOS plumbing, eventually a callback is
generated ->
the SDL handler for the callback raises an exception ->
back now to PollEvent (if iOS doesn’t catch exceptions in the callbacks),
which catches the exception, returns a “high priority” event (SDL_LOWMEM
for example)
app gets that event, handles it

If exceptions are not an option, could a similar set up be accomplished
with setjmp/longjmp as it’s already being done in UIKit_PumpEvents ?

Another more general idea, is adding a SDL_RegisterEventHandler sort of
function, which if used will put SDL in a “event driven” mode (useful for
iOS, NaCl, perhaps others), where you don’t have to pump events.

–
Gabriel.

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