• 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: NSDocument reference held by NSSavePanel?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSDocument reference held by NSSavePanel?


  • Subject: Re: NSDocument reference held by NSSavePanel?
  • From: Quincey Morris <email@hidden>
  • Date: Mon, 13 Apr 2009 11:01:36 -0700

On Apr 13, 2009, at 10:07, Michael Ash wrote:

I'm confused. If you can't stand six years then you can't rely on
-finalize. Nothing guarantees that it will *ever* be called in a
timely fashion.

No need to be confused. I was just admitting your correctness and then hiding behind a smiley face.


However, the part I didn't say before was the question of whether a garbage collector that didn't collect unreferenced objects in a *reasonably* timely fashion was or was not defective. (And, yes, "timely" is somewhat elastic here.)

If the answer is that it might take six years (i.e. more or less never) then your earlier statement can't be true in any practical sense:

-finalize should do two things. First, it should clean up any memory
allocations that aren't managed by the collector, like malloc blocks.
Second, it should clean up non-memory resources *as a fail-safe*. It
should close file descriptors, release shared locks, what have you,
but only to ensure that they weren't forgotten.

If you can't be sure when finalize will be called, then these *fail- safe* activities aren't fail-safe at all. Waiting six years to clean up memory allocations that aren't managed by the collector, or waiting six years to clean up non-memory resources, even as a fall-back position, makes no sense, so there's no sense in coding the cleanup in a finalize. In fact, if you have to treat finalize as if it isn't going to be called for six years, then there's absolutely no practical use of finalize at all.


So, if the garbage collector can be expected to run within a couple of seconds (or maybe even tens of seconds, if other application threads are busy computing away), it makes sense to use finalize for non-time- critical, fail-safe or fall-back resource deallocation. But if it can take *much* longer than that, then you either have to give up finalize completely, or declare the garbage collector defective.

At least, that's the argument that suggests itself to me. But I'm not insisting on its validity, which is why I didn't go OT with it earlier.


_______________________________________________

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: NSDocument reference held by NSSavePanel?
      • From: Michael Ash <email@hidden>
    • Re: NSDocument reference held by NSSavePanel?
      • From: David Scheidt <email@hidden>
References: 
 >NSDocument reference held by NSSavePanel? (From: Quincey Morris <email@hidden>)
 >Re: NSDocument reference held by NSSavePanel? (From: Michael Ash <email@hidden>)
 >Re: NSDocument reference held by NSSavePanel? (From: Quincey Morris <email@hidden>)
 >Re: NSDocument reference held by NSSavePanel? (From: Michael Ash <email@hidden>)

  • Prev by Date: Simple mac server app seems can't receive incoming connection (code signing problem?)
  • Next by Date: Re: Dynamically getting the type of ivars
  • Previous by thread: Re: NSDocument reference held by NSSavePanel?
  • Next by thread: Re: NSDocument reference held by NSSavePanel?
  • Index(es):
    • Date
    • Thread