Sockets and finalisation

Michael Roberts mike at mjr104.co.uk
Thu Jan 22 22:41:06 UTC 2004


On Thu, Jan 22, 2004 at 10:42:54PM +0100, Andreas Raab wrote:
> The thing to keep in mind for all of the places where finalization is
> provided in the image is that finalization is ALMOST NEVER a replacement for
> proper resource management. 

ok, thanks

> > If I have an object aNode that holds onto aSocket then
> > <snip>
> 
> No. It is because finalization is only run if the object is GCed and your
> inspector will hold a live reference to aNode and aNode will hold a live
> reference to the socket and so the socket doesn't get GCed. (note that the "
> chase pointers" feature can be misleading as it is assumed that for this
> feature you are interested in "all but" the reference paths starting from
> the inspector you hold).

sorry, I meant if the inspector was holding the only instance and I close the inspector the socket seems to survive.  or possibly survives because it is connected?  I think ConnectionQueue survives GC without any references to it but I know there is a method on it to clean up.  Anyway, I agree I'm just being lazy and should write some proper management of them.

I guess that recently I have been doing a lot of work in inspectors and create and close them with much gusto.  In some respects it would be good if my objects could be better citizens if I don't send the object an appropriate message before closing the inspector.  But I wouldn't rely on this in a more complex system.

> 
> > If I wanted the semantics that after dropping aNode
> > I wanted to send closeAndDestroy to its socket I feel
> > I might want to head in the area of finalisation but
> > I don't know how to do this.
> 
> This depends on what you consider "dropping" aNode. 
I mean closing the inspector on an object that references (say) a connected socket.

>If you mean "wait until
> it is GCed" rather than somehow explicitly "shut down", then you _may_ want
> to use finalization. If so, have a look at Object>>toFinalizeSend:to:with:.
ok, I'll look at that to understand finalization but I'll manage the resources properly.

I've only just started learning about sockets, processes and semaphores so I have done quite a bit of manual cleaning up in the image when I've left various object hanging by closing the inspectors.

> 
> > What is the best, or considered, way to handle processes
> > in objects when you then forget about the object without
> > cleaning up the process.  
> 
> It depends. A process blocking on a semaphore WILL get GCed if the
> associated semaphore gets GCed. For example:
> 
> | process sema weakObserver |
> sema := Semaphore new.
> process := [sema wait] forkAt: Processor userInterruptPriority.
> weakObserver := WeakArray with: process.
> "No GC both semaphore and process"
> process := sema := nil.
> Smalltalk garbageCollect.
> "lo and behold! it's gone"
> weakObserver first.
> 
> So if you'd have a process blocking on a semaphore in a socket, all of
> socket, semaphore and process are likely to "go away" at the same time.
> 
ok, I'll play with this
thanks!
Mike



More information about the Squeak-dev mailing list