Re: Phil meet y-devel; y-devel meet Phil

Thomas wrote:

> On Wednesday 21 July 2004 11:35, Ulrik Mikaelsson wrote:
>>Hmm, is it possible to do useful GC:ing on a network-protocol with
>>different client-implementations? For instance, how would the server know
>>if a client is REALLY still using it's reference to an object? Is it
>>possible to garbage-collect memory, or even detect memory leaks from a
>>misbehaving client?

It can never be safe to destroy a valid object owned by a connected 
client (an object should become invalid when the client notifies the 
server that it is finished with it), since there is no way to guarantee 
it has really forgotten it.  We might need an assassin function to kill 
those clients which have too many apparently unused server objects, but 
this should only be used when there are insufficient resources on the 
server (like the Linux OOM killer).  Allowing for the server to 
unilaterally delete objects which may still be valid is too risky.

Side note: Since the client and server are separated by the protocol, a 
memory leak in the client can never be detected by the server.  It's 
also pretty much impossible to detect a memory leak in a running program 
when this is not the case.

> One simple way to tell is to keep a client reference count for each object, 
> which would only keep track of how many clients hold references to an object.  
> When that count reaches zero (and you might have a server flag which would 
> keep this from being garbage collected), the resource could be freed.  This 
> way, the GC would only need to be run each time a client disconnects, 
> reducing overhead.

I am reasonably sure that for those objects which can be destroyed it 
will only be possible for one client to have a reference to that object 
anyway.  Of course, it may be that that client has multiple references 
to the same thing, but I would imagine it will be cleaner to have the 
client end of things handle mapping multiple refernces onto a single 
server object.

This removes a lot of complexity.

Phil