[gclist] Destructor functions and GC

[David Ungar]

Dave,

I sympathize a lot!  Sometimes people state assumptions/goals
you like, but then somehow come up with conclusions you cannot
understand.

- Dave Ungar


>Hans said:
>>In my mind, the real issue isn't this example, but whether or not it's
>>possible
>>to give the programmer clean rules for writing correct code.  If you
>>don't have
>>ordering guarantees, it seems to me that you violate abstraction
>>boundaries all
>>over the place.  The file buffer contains a file handle.  It shouldn't have to
>>know whether or not that's a magic integer, or a pointer to another object or
>>whether the other object has finalization enabled.  If you don't ensure proper
>>ordering, you're saying that the finalization code may access certain fields
>>but not others, and which fields may be accessed depends on implementation
>>internals for those fields.
>>
>>As Charles points out, imposing the ordering constraint doesn't completely
>>avoid the problem.  There are still cases in whcih you have to put more stuff
>>in the interfaces than you would like.  But those cases are even less
>>frequent.
>>And if you ignore the problem you get an easily detectable leak instead of
>>incorrect results or a crash.
>
>I don't understand the abstraction boundary argument in this example.
>Whether or not the file handle is closed manually or finalization is
>used, there is a clear relationship between the buffers and the file
>handle, which together are implementing an abstraction (eg. stream).
>The file handle has to know about the buffers in the sense that the
>buffers have to be flushed before the file handle is closed, and the
>buffers have to know about the file handle in the sense that they use
>it when they fill up.  So it's no big loss of encapsulation to have the
>finalization code, whatever it is, obey the same rules that explicit
>closing code would have had to follow.
>
>I suspect I'm missing your point, because I don't see why you say this
>has anything to do with whether the file buffer knows about the
>internal representation of file handles.  Doesn't the encapsulation
>argument work the opposite way?  If the programmer has to reason about
>the heap topology (ie. acyclicity) to write correct finalization code,
>then you are _requiring_ the abstraction violation.  If there aren't
>finalization ordering guarantees based on pointer structure, this
>doesn't come up.
>
>I don't understand the crashing argument either.  Where are crashes
>coming from?  I'm been talking about a system where deallocation (as
>opposed to finalization) never occurs while an object is reachable,
>even after finalization, so pointers are always valid.  Are you talking
>about something other than dangling pointers?
>
>I'm getting the impression that there is a fundamental miscommunication
>here.  I find myself agreeing with all your points - for example, that
>programmers must be given clean rules for writing correct code, and
>that finalization should not violate abstraction boundaries - but then
>I reach entirely different conclusions.  Perhaps we're just coming at
>it from very different camps; I'm been deliberately ignoring the needs
>of a finalizer meant to coexist with C++ destructors - useful though
>such a thing may be.
>
>Pardon my late response, I inexplicably stopped getting the list when I
>switched over to gclist-digest, and am replying cut-and-paste from the
>archives.
>
>    - Dave
>
>--
>David Stoutamire
>http://www.icsi.berkeley.edu/~davids

-- Dave