• 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: Releasing ivars in -didTurnIntoFault. Should set to nil?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Releasing ivars in -didTurnIntoFault. Should set to nil?


  • Subject: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • From: "Georg C. Brückmann" <email@hidden>
  • Date: Thu, 13 Aug 2009 22:33:18 +0200

In fact, relinquishing ownership of the connection during this method is simply a bug. If you're its owner, you're responsible for preventing it from being deallocated while it's still alive -- and it's still alive.

In this case, you're pretty sure that autoreleasing it keeps it from being deallocated long enough for its lifetime to end, but that's not a safe general assumption. What if the object you're releasing has a pending error message it's going to display after a timer expires (i.e. after the autorelease pool has been drained)?

I think it’s a pretty sane assumption that the delegating *may* still access its reserved memory after the delegate method returns. If the delegating object has to execute further code in a future run loop cycle, then it’s the object’s responsibility to ensure it’s still alive. After all, it told its delegate that it had finished.
Also, I’d consider any implementation that doesn’t invalidate any pending timers when deallocating/finalizing previously created flawed.


So, in such cases, you have an object lifetime issue that must be solved on a case by case basis. Sometimes -- maybe most times -- autoreleasing might be an answer, but I don't think that recommending the use of 'autorelease' over 'release' *as a routine safety precaution* is a viable position to take.

Well, is there any disadvantage when autoreleasing? (I’m not talking about tight loops here – that’s another topic.) Generally speaking, releasing a delegating object, when it notifies its delegate that it’s finished, should be fine from the delegate’s point of view.


Also, I’m interested what method of reference releasing you’d recommend, because the timer issue mentioned above would be equally present when releasing instead of autoreleasing.

Note that I don’t want to persuade you, I just don’t see any disadvantage of autoreleasing while I do see a slight advantage.

– Georg

_______________________________________________

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: Releasing ivars in -didTurnIntoFault. Should set to nil?
      • From: Quincey Morris <email@hidden>
References: 
 >Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Jerry Krinock <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: "Sean McBride" <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Dave Keck <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: "Georg C. Brückmann" <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Quincey Morris <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: "Georg C. Brückmann" <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Quincey Morris <email@hidden>)

  • Prev by Date: File's owner, outlets and methods
  • Next by Date: Re: NSPredicate & Editor questions
  • Previous by thread: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • Next by thread: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • Index(es):
    • Date
    • Thread