Re: "Capturing 'self' strongly in this block is likely to lead to a retain cycle"

  • >> In practice, NSOperationQueue probably releases the block when it's done with it
    >
    > I'm curious about your use of the word "probably" here. Can you explain?

    This is probably not what the OP had in mind, but I might mention that I've seen situations where autoreleases associated with NSOperationQueues and GCD queues have still been outstanding five minutes later under conditions of extremely high load. (My suspicion is that a mouse click or other user event causes these to be carried out, but I didn't test that one systematically).
  • On Jul 10, 2012, at 12:56 AM, Jonathan Taylor wrote:

    >>> In practice, NSOperationQueue probably releases the block when it's done with it
    >>
    >> I'm curious about your use of the word "probably" here. Can you explain?
    >
    > This is probably not what the OP had in mind, but I might mention that I've seen situations where autoreleases associated with NSOperationQueues and GCD queues have still been outstanding five minutes later under conditions of extremely high load. (My suspicion is that a mouse click or other user event causes these to be carried out, but I didn't test that one systematically).

    GCD creates autorelease pools of "last resort" - they are basically only there to prevent what would otherwise be unavoidable leaks if they were not present. Because the threads that own these autorelease pools have an undefined lifetime, the lifetime of these autorelease pools can similarly be exceptionally long.

    Basic rule of thumb thus is to create your own autorelease pool for such blocks or operations to ensure that your autoreleases are carried out in a timely manner. This is not unlike how you create your own autorelease pools when creating a new NSThread.
    --
    David Duncan
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today