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 (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
