[SDL] [patch] OS X carbon SDL_WINDOWID support

Bob Ippolito bob at redivi.com
Fri Sep 22 18:20:12 PDT 2006

On 9/22/06, earl <earl at stanfordalumni.org> wrote:

> On a related topic, I've found what I think is a bug in the thread code
> for OS X.  My application creates threads, and I see scary run-time
> warnings in stderr about leaking of various cocoa objects that were
> allocated in those threads.  According to Apple, "If you are making
> Cocoa calls outside of the Application Kit's main thread, however, you
> need to create your own autorelease pool. This is the case if you are a
> Foundation-only application or if you detach a thread."
> http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html
> I find that calling the following code from my newly created thread
> fixes the leaking warnings:
>      NSAutoreleasePool *pool;
>      pool = [[NSAutoreleasePool alloc] init];
> Then when the thread is being destroyed we should release the pool:
>      [pool release];
> I believe that SDL should be doing these things in its thread creation
> and destruction code, but I'm not sure where the right place is to put this.

That's really not how you want to do it, unless the threads are short
lived. The idiom for maintaining NSAutoreleasePool is that you should
release them periodically, the main thread does this after each
iteration of the event loop for example. Otherwise you're effectively
leaking memory for the lifetime of the thread.

What you're seeing means one of two things: you're either doing
something that you shouldn't, or SDL isn't guaranteeing an
NSAutoreleasePool in the safe-for-alternate-thread functions where it
happens to use Objective-C. Only the latter should be patched, but
someone would have to track down exactly where this is happening (the
stderr spew should say which function to set a breakpoint on).


More information about the SDL mailing list