Re: Garbage collector bug

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Shital Shah (shital_at_orioninc.com)
Date: 03/21/04 

Date: Sat, 20 Mar 2004 21:20:35 -0500

I think this chain of thoughts is missing a point. Continuing with your
analogy of subscribing a mailing list, in perfectly working world, yes I
need to inform list server that I'm dead or I have moved so it can remove me
from it's list. But the entire purpose of having a .Net garbage collector is
that I never have to worry about memory deallocation if I'm in 100% managed
world. So I'm supposed to allocate memory as and when I need [equ to
subscribing a list] but can get away with having it deallocated myself [equ
to unsubscribing]. In terms of your analogy, if mailing list finds out that
mails are being returned because I'm dead or have moved, it should
automatically unscribe me if it works .Net way. If it works C++ way, yes, I
need to tell that server. In fact this is the way most mailing list such as
Yahoo! Groups works today.

Having said that, the important point is that once I set variable to null,
I've lost the reference. There is NO way I can get that reference back and
so keeping with GC theory, it MUST be collected because it's not accessible
by anyway. The CLR delegate implementation is simply consuming this
reference for it's internal working which programmer should not care about
neither should expect to work around by forcing IDisposible on everything in
their code that listens to some events. Just a thought that there is a dead
object seating in my memory listening to events and doing funny things
without my knowledge is scary and can produce hard to debug behavior. I
certainly can explain why it's happening but there is no excuse that it
should not be.

Shital.

"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:eY6kfBgDEHA.3664@TK2MSFTNGP10.phx.gbl...
> ....
>
> > This is a real trouble maker. In so many situations we create many
objects
> > listening to an event from some other object. These listener guys won't
go
> > away until that event generator object goes away. The only .Net way to
get
> > around this would be to implement IDisposible which will remove event
> > handlers and calling Dispose over the listners. This is the reason I
want
> to
> > consider this behavior has a bug because it makes event handlers look as
> if
> > they are system resources which needs to be disposed.
>
> Ah, but they are. Say you maintain a mailing list. I subscribe to the
> mailing list, and so you send me notices. If I die or move, you can
expect
> me to inform you that I moved.
>
> The object which subscribes to the event has the obligation to unsubscribe
> when it no longer wishes to receive notifications. In the special case
> where both the publisher and subscriber will go out of scope together, you
> can skip this, but any object handling events generated by an object of
> significantly longer lifetime should be Disposable and should unsubscribe
> itself when it's disposed.
>
> David
>
>

Quantcast