Thank you very much Mike and Ken, spot on. Amazing this issue hasn't
gotten more attention, seems like a pretty big issue.
On Dec 15, 2008, at 5:46 PM, Ken Ferry wrote:
No, you're on target.
The thing to understand is that the implementation of the main event
loop is basically this:
while (1) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSEvent *event = [self nextEventMatchingMask…];
[self sendEvent:event];
[pool drain];
}
The key part is the call to next_EVENT_matchingMask. That means that
if there are no literal NSEvents to process, that call will never
return, and the autorelease pool will never drain. An NSTimer firing
does not involve a literal NSEvent, and that method won't return.
You can work around it by posting an application defined event at the
end of whatever code you have that you'd expect to behave like an
event with respect to pool draining. You should also consider filing
a bug that something or other ought to be making an autorelease pool
if you can figure out what 'something' is.
For example, someone filed a bug like that for timer firing, and as of
(I believe) 10.5, there's an explicit autorelease pool in the
timer-firing code. So timers shouldn't be a problem. But there may
be other kinds of run loop sources that don't have explicit pools,
particularly if you start using CF stuff since CF is below the concept
of autorelease pools.
-Ken
On Mon, Dec 15, 2008 at 6:53 PM, Chad Podoski <c...@bluelavatech.com>
wrote:
I have a process that is uploading images. My issue is as
following, when
uploading a large number of images and my application does not have
focus,
memory usage continues to climb until it is maxed out, causing the
app to
hang/crash. On the other hand, if the app has focus and the user
clicks
anywhere in the app, memory is released and memory usage stays low.
While
this is occurring in the main thread, the actually connection work
is being
done in a separate thread (via ConnectionKit). The action of the user
clicking in the app appears to trigger an interrupt, allowing memory
to be
released or the main thread to manage its autorelease pools. Couple of
questions:
1) Why is the main thread not managing the autorelease pool(s)
without this
user interrupt?
2) Is there a way to trigger the main thread to cleanup its
autorelease
pools?
3) If not, is there a way to simulate the user click or trigger the
same
underlying reaction to it, programmatically?
4) Am I completely off base with my hypothesis?
Thanks,
Chad
_______________________________________________
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/kenferry%40gmail.com
This email sent to kenfe...@gmail.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 arch...@mail-archive.com
