"John M McIntosh" <johnmci at ibm.net> wrote...
[and I think John actually knows most of what's here.  I just felt there was more to be said]
>As pointed out one of the strange things that one can do in some flavors of
>Smalltalk is take back an about to be GCed object. As part of finalization
>you can make a strong reference and effectively forbid the GCing of the
>object. Mind you it makes my head hurt why you would want to do this!

Well, in a perfect world, you should never have to.  But there are reasons.  Usually they have to do with tracking some other system without the benefit of actual references.  The most common example is to close or delete a file when ST no longer refers to it.  If the file operations were embedded in a transaction, then control could not emerge to the point of releasing the file without proper wrap-up.  Or if the file mechanism were all in ST (*), the GC could sweep it away and no one would be the wiser.  That's how it's supposed to be.  But the truth is that there usually IS another reference to the bits on the disk, but ST can't see it.  So finalization in such cases provides a mechanism for ST to retrieve the external reference, make it visible, and complete the transaction in an appropriate manner.

>Regarding Latency, an example. Given this simplified code
>
>thing isAnOrange ifTrue: [Transcript show: thing color]
>
>Many times I've seen a walkback, nil does not understand color, but what
>happened, how could thing which just responded to the isAnOrange message
>become nil? Well a GC occur and thing just well disappeared.

Let me know if this ever happens in Squeak.  I don't believe this particular example is in any gray area -- it's flat wrong.  The variable 'thing' should hold onto its referent throughout this expression.  I can't imagine using a system with this problem.

I have seen such a thing happen in Smalltalk, but it was due to a reentrancy bug where there was shared access to the variable 'thing', another process got tirggered between the two sends, set 'thing' to nil, and then gave control back.  But that's not what you were talking about.

I can also imagine a perverse situation where isAnOrange does a become operation, but that's not what you were talking about either.

	- Dan

(*) by this I mean a scheme whereby all file writing goes into an internal structure, and only gets put on disk and into a directory as part of the 'close' operation.