• 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: Autorelease/Retain/Release
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autorelease/Retain/Release


  • Subject: Re: Autorelease/Retain/Release
  • From: Charlton Wilbur <email@hidden>
  • Date: Tue, 24 Jul 2007 23:22:50 -0400


On Jul 24, 2007, at 11:01 PM, mmalc crawford wrote:


On Jul 24, 2007, at 7:18 PM, Tim Davis wrote:

As Charlton put it, the autorelease pool is sometimes quirky as to when it actually gets rid of objects, so I would actually be better off releasing it myself, and keeping the autorelease uses to things like looping through an XML doc or creating one (in this example anyways).

No, this is not correct.

The autorelease pool is *not* quirky as to when it actually gets rid of objects; it sends a release message to all objects that have been autoreleased within its scope when it is itself released. That's it. There is no "quirkiness".

I did not say it was quirky; I said that the memory management contract in Cocoa is that the autorelease pool releases its objects "at some point in the future," not "when the current block finishes execution." If you created an autorelease pool, you control when it sends the release messages, but if you're using another autorelease pool, it depends on where the autorelease pool comes from.


It's not hard to envision an autorelease pool optimization in a framework where the release message is only sent if there are a certain number of objects in the pool, though whether it would actually provide a performance increase is doubtful; and if there's no Cocoa event loop, such as in a shell tool, there may be a single autorelease pool that's created at the start of the program and released at the end; code that uses autorelease, such as classes that may be called as part of a shell tool or as part of a Cocoa application shouldn't make assumptions about when the objects are released, because there's no guarantee in the contract.

This is not "quirkiness"; this is "the contract only guarantees what the contract actually guarantees."

Charlton


-- Charlton Wilbur email@hidden 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: Autorelease/Retain/Release
      • From: Bill Bumgarner <email@hidden>
    • Re: Autorelease/Retain/Release
      • From: Michael Watson <email@hidden>
References: 
 >Autorelease/Retain/Release (From: Tim Davis <email@hidden>)
 >Re: Autorelease/Retain/Release (From: Nick Zitzmann <email@hidden>)
 >Re: Autorelease/Retain/Release (From: Tim Davis <email@hidden>)
 >Re: Autorelease/Retain/Release (From: mmalc crawford <email@hidden>)

  • Prev by Date: Re: CoreData: Preventing fault firing
  • Next by Date: Re: Autorelease/Retain/Release
  • Previous by thread: Re: Autorelease/Retain/Release
  • Next by thread: Re: Autorelease/Retain/Release
  • Index(es):
    • Date
    • Thread