Idea: GC and IDisposable

#11 09-25-2007, 01:57 AM

On 24 Sep., 22:46, "Hilton" <nos...@nospam.com> wrote:
> Hi,
>
> I'm sure I'm simplifying things here, but how about if the GC did this to
> objects that implement IDisposable:
> 1. Always Generation 1 (I think that is the correct name)
> 2. Get aggressive with them:
> a. Nuke 'em on a GC.Collect call (or equivalent)
> b. Call Dispose on the object.
>
> Yes, I understand that the compiler and the GC doesn't know what IDisposable
> is, but surely it is a worthwhile consideration? This garbabe/resource
> collection is particularly important in the CF world.
>
> Hilton

I have to agree with the other posters here, I don't think this should
be something the GC handles by itself.
However, if you want your own classes to exhibit a similar behavior,
you could implement a finalizer that calls Dispose and call
GC.SuppressFinalize(this) if Dispose is called manually.
That makes sure that Dispose does get called, even if its in a non-
deterministic way. I believe this method still causes a small overhead
for using a finalizer (even if its not used), but I still do it with
classes that implement IDisposable to make sure clean-up happens at
some point.

hth,
Kevin Wienhold

#12 09-25-2007, 02:37 AM

"KWienhold" <hedovvwr@trashmail.net> wrote in message
news:1190699855.807268.213050@r29g2000hsg.googlegr oups.com...
> On 24 Sep., 22:46, "Hilton" <nos...@nospam.com> wrote:
>> Hi,
>>
>> I'm sure I'm simplifying things here, but how about if the GC did this to
>> objects that implement IDisposable:
>> 1. Always Generation 1 (I think that is the correct name)
>> 2. Get aggressive with them:
>> a. Nuke 'em on a GC.Collect call (or equivalent)
>> b. Call Dispose on the object.
>>
>> Yes, I understand that the compiler and the GC doesn't know what
>> IDisposable
>> is, but surely it is a worthwhile consideration? This garbabe/resource
>> collection is particularly important in the CF world.
>>
>> Hilton
>
> I have to agree with the other posters here, I don't think this should
> be something the GC handles by itself.
> However, if you want your own classes to exhibit a similar behavior,
> you could implement a finalizer that calls Dispose and call
> GC.SuppressFinalize(this) if Dispose is called manually.
> That makes sure that Dispose does get called, even if its in a non-
> deterministic way. I believe this method still causes a small overhead
> for using a finalizer (even if its not used), but I still do it with
> classes that implement IDisposable to make sure clean-up happens at
> some point.

Whoa, wait. Finalize should NEVER call Dispose to clean up managed
resources, since the maaged resource references may no longer exist!

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

#13 09-25-2007, 03:12 AM

Hilton <nospam@nospam.com> wrote:
> > If you are not aware of the lifespans of the objects that you are
> > using, then that is an error, either in design, or implementation, or the
> > understanding of the underlying technologies and it should be fixed. If
> > something implements IDisposable, that should be a huge red flag that
> > tells the developer "hey, YOU (not the GC) need to pay extra attention to
> > me, as I am doing something that you want to pay attention to, and not
> > just leave lying around."
>
> That's a great argument for using free/malloc instead of a GC. A GC is
> there so that you don't have to worry about this stuff.

No, a GC is there so that you don't have to worry about this stuff *for
memory resources*. Not for other resources.

> All we've done is reduce the set of objects we're watching from "all" to
> "some".

That's a pretty big improvement, IMO.

> I'm saying that by adding a "if (!Disposed) o.Dispose()" would solve a
> lot of bug and memory leaks - we see them here all the time.

No, it wouldn't. You'd still have race conditions - you'd just see them
*slightly* less often, making them harder to find and fix. Any
IDisposable which directly has a handle on an unmanaged resource should
have a finalizer which calls Dispose anyway.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

#14 09-25-2007, 04:03 AM

Hilton wrote:
> [...]
> Your code is not affected, you can continue to optimize, but the GC will
> dispose of any objects that need to be disposed, but weren't. Sounds good
> to me.

I'm not sure I understand the point you're trying to make. How is what
you're suggesting different from the already-existing finalizer
paradigm? Other than the fact that the finalizer needs to explicitly be
written to call Dispose(), I mean.

Is that all it is? Or is there something different you're getting at?

Pete

#15 09-25-2007, 04:06 AM

Doug Semler wrote:
> [...]
> Whoa, wait. Finalize should NEVER call Dispose to clean up managed
> resources, since the maaged resource references may no longer exist!

I don't disagree. But I was just assuming that we were talking about
unmanaged resources here. After all, those are the ones that cause the
most trouble if not disposed properly.

Did I miss something?

Pete

#16 09-25-2007, 04:20 AM

On 25 Sep., 08:37, "Doug Semler" <dougsem...@gmail.com> wrote:
> "KWienhold" <hedov...@trashmail.net> wrote in message
>
> news:1190699855.807268.213050@r29g2000hsg.googlegr oups.com...
>
>
>
>
>
> > On 24 Sep., 22:46, "Hilton" <nos...@nospam.com> wrote:
> >> Hi,
>
> >> I'm sure I'm simplifying things here, but how about if the GC did this to
> >> objects that implement IDisposable:
> >> 1. Always Generation 1 (I think that is the correct name)
> >> 2. Get aggressive with them:
> >> a. Nuke 'em on a GC.Collect call (or equivalent)
> >> b. Call Dispose on the object.
>
> >> Yes, I understand that the compiler and the GC doesn't know what
> >> IDisposable
> >> is, but surely it is a worthwhile consideration? This garbabe/resource
> >> collection is particularly important in the CF world.
>
> >> Hilton
>
> > I have to agree with the other posters here, I don't think this should
> > be something the GC handles by itself.
> > However, if you want your own classes to exhibit a similar behavior,
> > you could implement a finalizer that calls Dispose and call
> > GC.SuppressFinalize(this) if Dispose is called manually.
> > That makes sure that Dispose does get called, even if its in a non-
> > deterministic way. I believe this method still causes a small overhead
> > for using a finalizer (even if its not used), but I still do it with
> > classes that implement IDisposable to make sure clean-up happens at
> > some point.
>
> Whoa, wait. Finalize should NEVER call Dispose to clean up managed
> resources, since the maaged resource references may no longer exist!
>
> --
> Doug Semler, MCPD
> a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
> The answer is 42; DNRC o-
> Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
> erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I was thinking of unmanaged resources, since those are normally the
ones that need to be cleaned up in the Dispose.
The GC handles cleaning up of managed resources just fine as far as I
know, so I don't really understand why one would even use IDisposable
on a class containing only managed resources.

Kevin Wienhold

#17 09-25-2007, 04:27 AM

KWienhold wrote:
> I was thinking of unmanaged resources, since those are normally the
> ones that need to be cleaned up in the Dispose.

Me too.

> The GC handles cleaning up of managed resources just fine as far as I
> know, so I don't really understand why one would even use IDisposable
> on a class containing only managed resources.

I suppose one reason might be if you had a class that you wanted to keep
a reference to, but you were only interested in some post-processing
state and wanted to go ahead and release whatever managed resources were
used to get to that state.

I can't think of a class off the top of my head that uses Dispose() in
that way, but it wouldn't surprise me if it exists.

But this isn't a case where you need the GC to do the Dispose() for you.
It's more an example of explicitly controlling the lifetime of resources.

Pete

#18 09-25-2007, 04:47 AM

On 25 Sep., 10:27, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.com> wrote:
> I suppose one reason might be if you had a class that you wanted to keep
> a reference to, but you were only interested in some post-processing
> state and wanted to go ahead and release whatever managed resources were
> used to get to that state.
>
> I can't think of a class off the top of my head that uses Dispose() in
> that way, but it wouldn't surprise me if it exists.
>
> But this isn't a case where you need the GC to do the Dispose() for you.
> It's more an example of explicitly controlling the lifetime of resources.
>
> Pete

That might be a reason, but in my mind it would violate the intent of
IDisposable. Maybe I'm nitpicking here, but if I saw someone call
Dispose on an instance and then use that instance afterwards I'd be
seriously confused.
Disposing something tells me that the instance is left in an unknown
state and shouldn't be used.
I'd probably use some another, properly named method to provide this
kind of cleanup.

Kevin Wienhold

#19 09-25-2007, 06:00 AM

KWienhold <hedovvwr@trashmail.net> wrote:
> That might be a reason, but in my mind it would violate the intent of
> IDisposable. Maybe I'm nitpicking here, but if I saw someone call
> Dispose on an instance and then use that instance afterwards I'd be
> seriously confused.
> Disposing something tells me that the instance is left in an unknown
> state and shouldn't be used.

Not necessarily. From the docs for IDisposable:

<quote>
Use this method to close or release unmanaged resources such as files,
streams, and handles held by an instance of the class that implements
this interface. This method is, by convention, used for all tasks
associated with freeing resources held by an object, or preparing an
object for reuse.
</quote>

Note the "or preparing an object for reuse". I can't think of any
examples where that actually *is* the use of IDisposable, but it would
be legal according to the docs.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

#20 09-25-2007, 06:15 AM

"Jon Skeet [C# MVP]" <skeet@pobox.com> ha scritto nel messaggio
news:MPG.2162ec9774bbcae14bc@msnews.microsoft.com. ..
> KWienhold <hedovvwr@trashmail.net> wrote:
>> That might be a reason, but in my mind it would violate the intent of
>> IDisposable. Maybe I'm nitpicking here, but if I saw someone call
>> Dispose on an instance and then use that instance afterwards I'd be
>> seriously confused.
>> Disposing something tells me that the instance is left in an unknown
>> state and shouldn't be used.
>
> Not necessarily. From the docs for IDisposable:
>
> <quote>
> Use this method to close or release unmanaged resources such as files,
> streams, and handles held by an instance of the class that implements
> this interface. This method is, by convention, used for all tasks
> associated with freeing resources held by an object, or preparing an
> object for reuse.
> </quote>
>
> Note the "or preparing an object for reuse". I can't think of any
> examples where that actually *is* the use of IDisposable, but it would
> be legal according to the docs.
>

Object pooling perhaps?

> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode