Re: menu madness with retain count
Re: menu madness with retain count
- Subject: Re: menu madness with retain count
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 27 Apr 2010 15:20:13 -0700
On Apr 27, 2010, at 3:05 PM, Uli Kusterer wrote:
> On 27.04.2010, at 23:22, Gary L. Wade wrote:
>> Calling -retainCount
>> immediately before and after the -setDelegate call is pretty much the only
>> way.
>
> Nope. It'll only lead to pain and suffering. And false positives. What if setDelegate was implemented thus:
>
> -(void) setDelegate: (id)dele
> {
> mDelegate = dele;
>
> [self detachNewThreadSelector: @selector(useDelegateOnThread:) withObject: dele];
> }
Grand Central Dispatch can confuse matters further and in subtle ways. Consider:
dispatch_async(..., ^{... time consuming maybe ...; dispatch_async(dispatch_get_main_queue(), ^{ ... dele ...}); });
In this case, the two dispatch_asyncs are going to call Block_copy() in a predictable order but with a high degree of variability in timing (both due to time consumed in outer block and workload on main queue). End result is that the retain count will be changing behind your back regardless of what you are doing in other threads. More confusing, still, if the scheduling of the inner block on the main queue happens before your code runs, but the block's execution is blocked by your code running on the main queue, you *might* see a retain from the first block and *will* see the retain from the second block.
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden