On Oct 2, 2008, at 11:46 AM, Ashley Clark wrote:
Looking at your other email to the list about this I think my issue was that I was passing the objects to a delegate method using an NSInvocation object and then in that delegate method sending them on to the main thread through a contextInfo memory reference.Like Oleg, I only saw the crash during periods of high activity on my second thread where a lot of objects were being created and destroyed. I was able to work around the problem by issuing a CFRetain in my delegate and then sending a CFRelease to it once I had it stored in scanned memory in the main thread.If I read your message correctly though I should also be CFRetain'ing and CFRelease'ing the objects I'm sending with my NSInvocation object as well? Does this only apply when invoking the invocation on the main thread from a secondary thread, or is it general practice?
Well... the conditions under which the objects might be collected out from under the NSInvocation are not entirely straightforward.
The most defensive approach is to CFRetain() and CFRelease() the objects on the way in/out of the NSInvocation.
Obviously, if the arguments are otherwise rooted, they won't be collected. Thus, there are a myriad of possible other ways to ensure that the objects stick around.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
