Re: Block Confusion...
Re: Block Confusion...
- Subject: Re: Block Confusion...
- From: R <email@hidden>
- Date: Tue, 31 Jan 2012 09:05:21 -0800 (PST)
never mind..... the class was getting dealloc. Still getting use to
ARC and new ivar techniques.
thanks!
On Jan 31, 9:16 am, R <email@hidden> wrote:
> My confusion is that the array in class A is used later in the code,
> it is just nil inside the block that is running on another thread.
>
> On Jan 31, 8:07 am, Fritz Anderson <email@hidden> wrote:
>
>
>
>
>
>
>
>
>
> > On 30 Jan 2012, at 8:56 PM, R wrote:
>
> > > One class creates a STRONG pointer to a NSMutableArray. It then
> > > passes that pointer to another class, which has a WEAK reference.
> > > that class is listed below. When I fork a new thread for the
> > > simpleBlock, I lose the pointer. I tried this on a fresh, very simple
> > > test and I did not have this behavior. It behaved as expected with
> > > the same memory address for all three logs.
>
> > I'll call "one class" ClassA, and "another class" ClassB.
>
> > Instances of ClassA have a strong reference to an NSMutableArray. Instances of ClassB borrow the array through a weak reference.
>
> > I think if you create a -[ClassA dealloc] method to log the deallocation of a ClassA, you'll find that the ClassA object is deallocated before the enqueued block uses the ClassB reference to the array. In a simple case (no other object has a strong reference to the array), the array gets deallocated, too. ClassB's reference being weak, the reference is nilled-out.
>
> > The call to [self checkMutableArray] causes the block to retain self, not the weakly-referenced array. The call isn't resolved until the block is run.
>
> > The other case worked only by chance. You should treat the timing and order of deallocation as though they were nondeterministic.
>
> > — F
>
> > _______________________________________________
>
> > 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
>
>
> > This email sent to email@hidden
>
> _______________________________________________
>
> 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
>
>
> This email sent to email@hidden
_______________________________________________
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