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

On Wednesday 21 July 2004 11:35, Ulrik Mikaelsson wrote:
> > > One other thing that might be
> > > relevant to consider is how to avoid unintentional memory-leaks in the
> > > server, as a result of an application behaving bad. For instance, an
> > > application should hopefully not be able to connect to a Y server and
> > > create thousands of objects, and then forget it's references to them.
> > > I don't think the Y server does garbage collection, and I don't think
> > > we can safely do garbage collection in the server, so we'll have to
> > > look elsewhere for a decent solution. Perhaps the QObject-solution is
> > > something that could be applied?
> >
> > While C doesn't natively sport a GC, it has been shown that you can in
> > fact use a GC with C. So if there is a way to elegantly put one in the
> > Y server, we could consider that. I'd prefer it so that it's an option
> > along with a CG without the coverup but with a noisemaker instead: a
> > memory leak detector. In an ideal world we'd never need either, but hey.
>
> 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?
>
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.

Of course, clients could still leak while they are running, but at least this 
will only last as long as the client is running, instead of the whole time 
the server is running.

Thomas Stephens
[email protected]