John, David,

Thanks for your replies.

No, I did not really sort out the problem, I simply quit unregistering
the objects, which of course made the symptoms go away. I suspect that
I was registering and unregistering things at a higher rate than would
typically be the case for file streams and sockets, so perhaps that
increases the likelihood of the problem.

I'll take another look at the socket and file stream examples and
see if I can spot where I went wrong.

By the way, I did try synchronizing access to the registry, which
indeed made the race condition go away. But some other horrible
problem cropped up, at which point I decided I was wasting my time
trying to violate the laws of nature. I'll have another look and
see if I can clarify what was happening.

On Wed, Jun 14, 2006 at 10:39:51AM -0700, John M McIntosh wrote:
> I'll also note MPEGFile uses the same pattern which was copied from  
> the Socket code originally.
> This pattern of code is used in other class I've written, (6 more in  
> Sophie) and if someone can find a bug in
> it this pattern of code would be interesting to know.
> 
> I'll note if your code does cleanup processing as part of an explicit  
> method send, then in the finalize
> method you may need a guard clause to prevent double usage of destroy  
> logic (which might cause problem).
> 
> 
> 
> On 14-Jun-06, at 10:13 AM, David Shaffer wrote:
> 
> >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
> >