• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Block Confusion...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Block Confusion...


  • Subject: Re: Block Confusion...
  • From: R <email@hidden>
  • Date: Tue, 31 Jan 2012 08:16:52 -0800 (PST)

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

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Block Confusion...
      • From: R <email@hidden>
References: 
 >Block Confusion... (From: R <email@hidden>)
 >Re: Block Confusion... (From: Fritz Anderson <email@hidden>)

  • Prev by Date: Window/Controller, View/Controller, View ?
  • Next by Date: Re: Block Confusion...
  • Previous by thread: Re: Block Confusion...
  • Next by thread: Re: Block Confusion...
  • Index(es):
    • Date
    • Thread