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

[Jeremy Jurksztowicz]

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 <gabomdq at gmail.com> wrote:

>
>
> 2012/3/22 Brian Barnes <ggadwa at charter.net>
>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120322/efecf55f/attachment.htm>