Re: NSDocument reference held by NSSavePanel?
Re: NSDocument reference held by NSSavePanel?
- Subject: Re: NSDocument reference held by NSSavePanel?
- From: Michael Ash <email@hidden>
- Date: Mon, 13 Apr 2009 20:33:18 -0400
On Mon, Apr 13, 2009 at 2:01 PM, Quincey Morris
<email@hidden> wrote:
> 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.
My apologies, "fail-safe" is the wrong term. The proper term would be
"extra precaution" or something of the like. Belt-and-suspenders,
without a 100% assurance that your suspenders will hold after the belt
fails.
As for the practical use of finalizers, they certainly have a
practical use beyond the "extra precaution" for scare resources:
cleaning up non-GC memory resources, of which there are many. One of
the most common reasons to write a finalizer is to free some structure
allocated with malloc.
You might respond to this with, well, what if you malloc 2GB of memory
from a 16-byte object and the collector decides that this object never
needs to be destroyed? The answer is, don't do that.
You simply can't count on the collector to collect your objects in a
timely fashion. It would be perfectly reasonable to write a GC that
always keeps, say, 10% garbage around at any given time, with no
guarantee that it's always the freshest 10%. Under such a regime your
object may be deemed unimportant and *never* freed.
You may conclude that finalizers aren't really all that useful. And
you'd be right! That's why I keep saying that you shouldn't rely on
the finalizer to be useful for this task.
By the way, this is not in any way a unique feature of Apple's
collector. Indeed, it's found in virtually every collector out there,
and the uselessness of finalizers is a common theme in GC languages.
Mike
_______________________________________________
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