Re: [AD] SF.net SVN: alleg:[14994] allegro/branches/5.1

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Sun Apr 22, 2012, Evert Glebbeek wrote:
> On 22 Apr 2012, at 22:04 , Elias Pschernig wrote:
> > Are you using OSX 10.6?
> 
> Yes.
> I'm also not planning to upgrade soon; 10.7 has nothing I want (feature
> wise)...
> 
> > You drain it periodically by creating and draining a pool in each
> > "tick". Cocoa does that in each of it's own GUI ticks. Allegro
> > obviously cannot work that way, unless we add a function which has to
> > be periodically called by the user.
> 
> Or something that Allegro can call itself behind the user's back. But that
> was basically why I didn't see how to do it easily. If I were to suggest
> adding a function to Allegro to do this, I'd suggest adding an event type
> that the user can listen to (say OS_CLEANUP_EVENT) and then as a response
> the user should call al_do_os_cleanup(). With better names, obviously. A
> bit ugly and not fool-proof (the user still has to do it), but in
> principle we could use this as a mechanism to add more periodic OS
> callbacks for platforms that need them. Other than that it's not a very
> neat and elegant solution. Then again, my gut instinct was to simply drain
> the pool from al_flip_display(), so in that light it's an improvement. :P
> 
> > Just creating a pool in the beginning of the thread then draining it
> > when the thread quits is useless, *if* my interpretation is right.
> 
> Depends on when the thread exits: if it exits during the lifetime of the
> program it's fine, but that (potentially) goes for threads created through
> Allegro's multi-threading interface. It doesn't apply to the thread we use
> to run the mangled main(), in which case things leak until the end of the
> program where they'd be realeased anyway. In that case the only purpose of
> the release pool is to not flood the console, which I still consider a
> desirable feature. ;)

I think a lot of other people would agree with that, at least for items we 
can't release ourselves for one reason or another. What not using a global 
pool allows, is us to find and fix all of our memory leaks. Any that are left 
after that can probably be stuck back in a global pool or hacked around in 
some way.

> > Just set a breakpoint to __NSAutoreleaseNoPool. It should give you a
> > full backtrace of the allocation which is attempted while no pool is in
> > place. I cannot do it myself since I only have access to OSX 10.7.
> 
> Ok, I'll see if I have some time to look at that tomorrow.
> 
> Evert
> ---------------------------------------------------------------------------
> --- For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx