Finalization question

David Shaffer cdshaffer at acm.org
Wed Jun 14 17:13:27 UTC 2006


David T. Lewis wrote:

>I have a case in which I want to register objects for finalization
>in order to ensure that external references (file handles on OS pipes)
>are closed if the object has not been properly closed by its user.
>I thought it would be a good idea to unregister these objects explicitly
>when I know that they *have* been properly closed. This seemed
>like a good idea because allowing weak registries to grow can be a
>big performance problem, and I thought it would be good to keep
>the registry as small as possible.
>
>The result appears to be an occasional race condition in which the
>finalization process attempts to remove an element that somebody else
>(me) has removed from another process. At least I think that's what's
>happening, see attached png of the debugger.
>
>Is explicitly removing an object from the finalization registry a
>Bad Thing To Do? Or is this perhaps a bug that should be resolved
>by synchronizing access to the finalization registry, or by ignoring
>the error condition in the finalization process?
>
>Thanks,
>
>Dave
>
>  
>
Did you ever sort this out Dave?  Looking at StandardFileStream I see
exactly the pattern you describe:

unregister method removes the file stream from the registry via
remove:ifAbsent:

close sends unregister

It seems odd that your race condition occurs but I've never had such a
problem with file streams.  Further investigation shows that Socket does
the same thing.  Maybe you could look at them and see where your usage
differs.  Is the problem Squeak version dependent?  I've looked over
WeakRegistry in 3.7 and it looks solid.  No obvious race
conditions...but they are never obvious, are they ;-)

David




More information about the Squeak-dev mailing list