Uli Kusterer wrote:
On 30.09.2008, at 21:01, James Walker wrote:
However, I did solve my problem. I neglected to mention that I'm
working in a mostly Carbon app. When I surrounded the alloc, init,
and showWindow calls with a local autorelease pool, the problem went
away and the NSWindowController gets deallocated without funny
business. I thought I had read that it was no longer necessary to set
up my own autorelease pools.
You probably already know that, but just in case:
1) Do not put an autorelease pool at the bottom of your event loop, i.e.
into your 'main' function so it surrounds the event loop run call. All
this will do is inhibit the 'NSAutoReleaseNoPool' error log messages.
Since that all-encompassing pool would take up all objects where no pool
existed, but would never be drained, you'd have the leaks without the
leak warning message.
I see, but no I didn't do that.
2) If you did your creation, destruction and testing in the same event
handler (even if it spawns its own sub-event-loop to e.g. run the Cocoa
window modally), then they'll all be in the same autorelease pool, so
you'll get a false leak. It's perfectly common to e.g. have another
autorelease pool inside a tight loop, to more frequently autorelease
objects that aren't needed after an iteration anymore. Carbon creates
its own pool in RAEL, but that won't be drained until the next event or
could (as a performance optimization) be drained only every fifth event
or so.
There was no sub-event-loop. The dealloc method never got called, no
matter how long I waited.
3) A common recommendation for progressive Carbon-to-Cocoa ports that
still need RAEL or WNE at the moment is to create a Cocoa app, start it
regularly using NSApplicationMain, and to call RAEL in
-applicationDidFinishLaunching:. If you're calling
ReceiveNextEvent()/SendEventToEventTarget() or
-nextEventMatchingMask/-sendEvent: in a tight loop at this spot, you
might not get the autorelease pool, and all objects will accumulate in
the pool set up by AppKit for -applicationDidFinishLaunching:, giving
you a similar effect as #1.
Well, I haven't progressed that far in going from Carbon to Cocoa.
Any of these ring a bell with regard to your project?
Nope, but thanks for trying.
--
James W. Walker, Innoventive Software LLC
<http://www.frameforge3d.com/>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
