IDisposable.Dispose is documented as the method where you have to release
unmanaged resources.
Dispose is called by Finalize.
Finalize is called by garbage collector after the object becomes
inaccessible.
The documentation says: "The thread on which the finalizer is run is
unspecified".

So the question is: My object has allocated a [win32] window handle using
CreateWindow (called using P/Invoke) and has to destroy it. But Win32 SDK
say that DestroyWindow has to be called from the same thread that called
CreateWindow. This seems impossible given Dispose/Finalize/GC patern.

Any advice ?

btw: Let me know if I should post to another group.
--
francois.piette@overbyte.be
The author for the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be

Re: IDisposable.Dispose, Object.Finalize and threads by David

David
Wed May 05 15:19:26 CDT 2004


"Francois PIETTE" <francois.piette@overbyte.be> wrote in message
news:409939ea$0$25074$a0ced6e1@news.skynet.be...
> IDisposable.Dispose is documented as the method where you have to release
> unmanaged resources.
> Dispose is called by Finalize.
> Finalize is called by garbage collector after the object becomes
> inaccessible.
> The documentation says: "The thread on which the finalizer is run is
> unspecified".
>
> So the question is: My object has allocated a [win32] window handle using
> CreateWindow (called using P/Invoke) and has to destroy it. But Win32 SDK
> say that DestroyWindow has to be called from the same thread that called
> CreateWindow. This seems impossible given Dispose/Finalize/GC patern.
>

Therefore you should implement IDisposable, but omit the finalizer. Client
code should be clearly warned that failure to call IDisposable.Dispose will
leak a winow handle.

David



Re: IDisposable.Dispose, Object.Finalize and threads by Chad

Chad
Thu May 06 02:59:05 CDT 2004

"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
news:uMXtE5tMEHA.644@tk2msftngp13.phx.gbl:
> Therefore you should implement IDisposable, but omit the finalizer. Client
> code should be clearly warned that failure to call IDisposable.Dispose will
> leak a winow handle.

Thats not a very good solution. Thats asking for trouble and in fact violates
the .NET guidelines in general.

I dont see any clean solutions either. Maybe a suspended thread for creating
and destroying - but that wont work either because the finalizer is not
allowed to make external calls.

Francois since I know you are a Borland user you might see what VCL.NET did
regarding this.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Re: IDisposable.Dispose, Object.Finalize and threads by Daniel

Daniel
Thu May 06 05:54:12 CDT 2004

But the Finalizer is not "supposed" to be called under normal circumstances.
It is a sign that the Dispose() was not properly called, as Dispose() should
call SuppressFinalize.

Look in the help for a section called "Implementing a Dispose Method". In
addition to explaining all this, it gives code for the recommended pattern.

There's a growing school of thought that goes so far to say the Finalizer
should even raise an Exception to make it clear there is a bug (the
Dispose() not being called). Your scenario seems like a good reason to do
that if the memory leak is a big issue.

"Francois PIETTE" <francois.piette@overbyte.be> wrote in message
news:409939ea$0$25074$a0ced6e1@news.skynet.be...
> IDisposable.Dispose is documented as the method where you have to release
> unmanaged resources.
> Dispose is called by Finalize.
> Finalize is called by garbage collector after the object becomes
> inaccessible.
> The documentation says: "The thread on which the finalizer is run is
> unspecified".
>
> So the question is: My object has allocated a [win32] window handle using
> CreateWindow (called using P/Invoke) and has to destroy it. But Win32 SDK
> say that DestroyWindow has to be called from the same thread that called
> CreateWindow. This seems impossible given Dispose/Finalize/GC patern.
>
> Any advice ?
>
> btw: Let me know if I should post to another group.
> --
> francois.piette@overbyte.be
> The author for the freeware multi-tier middleware MidWare
> The author of the freeware Internet Component Suite (ICS)
> http://www.overbyte.be
>
>
>



Re: IDisposable.Dispose, Object.Finalize and threads by Francois

Francois
Thu May 06 06:47:12 CDT 2004

> Francois since I know you are a Borland user you might see
> what VCL.NET did regarding this.

There are no problem with VCL.NET because in this context the destructor is
always explicitely called. The problem is with native .NET components when
they are used from languages likes C# where object destructors are only
called by the garbage collector.

--
francois.piette@overbyte.be
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be


"Chad Z. Hower aka Kudzu" <cpub@hower.org> a écrit dans le message de
news:Xns94E16FBEB9715cpub@127.0.0.1...
> "David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
> news:uMXtE5tMEHA.644@tk2msftngp13.phx.gbl:
> > Therefore you should implement IDisposable, but omit the finalizer.
Client
> > code should be clearly warned that failure to call IDisposable.Dispose
will
> > leak a winow handle.
>
> Thats not a very good solution. Thats asking for trouble and in fact
violates
> the .NET guidelines in general.
>
> I dont see any clean solutions either. Maybe a suspended thread for
creating
> and destroying - but that wont work either because the finalizer is not
> allowed to make external calls.
>
> Francois since I know you are a Borland user you might see what VCL.NET
did
> regarding this.
>
>
> --
> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
> "Programming is an art form that fights back"



Re: IDisposable.Dispose, Object.Finalize and threads by Chad

Chad
Thu May 06 07:04:32 CDT 2004

"Daniel Billingsley" <dbillingsley@NO.durcon.SPAAMM.com> wrote in
news:OW#94h1MEHA.3016@tk2msftngp13.phx.gbl:
> But the Finalizer is not "supposed" to be called under normal
> circumstances. It is a sign that the Dispose() was not properly called,
> as Dispose() should call SuppressFinalize.

Thats not correct.

Dispose and Finalize are not the same and in many cases you need both. ONLY
in cases that the Dispose releases the resources that Finalize does should
you call SupressFinalize. This is not the case in most instances.

A file access might be an exmaple that this is. In the Dispose you free the
file handle, but in the Finalize you do it in case the user did not call
Dispose.

> There's a growing school of thought that goes so far to say the
> Finalizer should even raise an Exception to make it clear there is a bug
> (the Dispose() not being called). Your scenario seems like a good
> reason to do that if the memory leak is a big issue.

Its problematic if the finalizer throws an exception. The GC generally just
ignores it and goes on. So who will see the exception?



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/

Re: IDisposable.Dispose, Object.Finalize and threads by Chad

Chad
Thu May 06 07:09:52 CDT 2004

"Francois Piette" <francois.piette@overbyte.be> wrote in news:409a267d$0$249
$4d4efb8e@read.news.be.uu.net:
> There are no problem with VCL.NET because in this context the destructor
> always explicitely called. The problem is with native .NET components

Thats not correct Francois. I know you and I are at odds a lot - but I am
giving two sessions on this at CTTM (SDC) so I know this area very very well
after weeks of research and experimentation. :)

BTW I forgot to tell you I was in Belgium again two weeks ago. But I'll be at
SDC next week. Would love if you can make it over an meet us just for even
lunch or something.

Ok back to tech.. In Delphi for .NET the destructors are NOT guaranteed to be
called. Destructors in Delphi are implemented as Dispose and are treated thus
the same. So unless the user calls Dispose (or Free or Destroy) from Delphi,
it will NOT be called.

> they are used from languages likes C# where object destructors are only
> called by the garbage collector.

Well kind of... C# destructors yes because they are implemented as a
finalizer. But a Delphi destructor is implemented as Dispose.....



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/

Re: IDisposable.Dispose, Object.Finalize and threads by Jon

Jon
Thu May 06 07:36:00 CDT 2004

Chad Z. Hower aka Kudzu <cpub@hower.org> wrote:
> "Daniel Billingsley" <dbillingsley@NO.durcon.SPAAMM.com> wrote in
> news:OW#94h1MEHA.3016@tk2msftngp13.phx.gbl:
> > But the Finalizer is not "supposed" to be called under normal
> > circumstances. It is a sign that the Dispose() was not properly called,
> > as Dispose() should call SuppressFinalize.
>
> Thats not correct.
>
> Dispose and Finalize are not the same and in many cases you need both. ONLY
> in cases that the Dispose releases the resources that Finalize does should
> you call SupressFinalize. This is not the case in most instances.

I disagree - in every case I can think of which I've come across,
Dispose releases the resources that the finalizer would other do.

Why would you *want* to wait until the object is finalized before
releasing resources if you've been explicitly told that the object will
no longer be used?

> A file access might be an exmaple that this is. In the Dispose you free the
> file handle, but in the Finalize you do it in case the user did not call
> Dispose.

So what's an example of it *not* being the case?

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

Re: IDisposable.Dispose, Object.Finalize and threads by Chad

Chad
Thu May 06 14:11:51 CDT 2004

Jon Skeet [C# MVP] <skeet@pobox.com> wrote in
news:MPG.1b04418d397844b498a868@msnews.microsoft.com:
> I disagree - in every case I can think of which I've come across,
> Dispose releases the resources that the finalizer would other do.

It depends on how the resources are used and if the Dispose is a "Close" or
not. But I guess in most cases it would be the same - but not all.

> Why would you *want* to wait until the object is finalized before
> releasing resources if you've been explicitly told that the object will
> no longer be used?

In some cases the Dispose is more of a "Close" and shares code. But I guess
that if it left resources too - that wouldnt be a commonly needed situation.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

Re: IDisposable.Dispose, Object.Finalize and threads by Jon

Jon
Thu May 06 17:10:30 CDT 2004

Chad Z. Hower aka Kudzu <cpub@hower.org> wrote:
> Jon Skeet [C# MVP] <skeet@pobox.com> wrote in
> news:MPG.1b04418d397844b498a868@msnews.microsoft.com:
> > I disagree - in every case I can think of which I've come across,
> > Dispose releases the resources that the finalizer would other do.
>
> It depends on how the resources are used and if the Dispose is a "Close" or
> not. But I guess in most cases it would be the same - but not all.

Possibly not all, although I'd be interested to hear of an example.
Have you heard of any?

> > Why would you *want* to wait until the object is finalized before
> > releasing resources if you've been explicitly told that the object will
> > no longer be used?
>
> In some cases the Dispose is more of a "Close" and shares code. But I guess
> that if it left resources too - that wouldnt be a commonly needed situation.

Indeed - and the fact that I can't think of a single situation where
it's the case is fairly telling, I think.

Certainly I believe that your statement that "This is not the case in
most instances" (with regard to Dispose calling SuppressFinalize) in
untrue. (The docs for Dispose even state: "However, once the Dispose
method has been called, it is typically unnecessary for the garbage
collector to call the disposed object's finalizer.")

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

Re: IDisposable.Dispose, Object.Finalize and threads by JD

JD
Thu May 06 18:32:32 CDT 2004

The dataview is the only class that I have seen that "kind of" does the
close/dispose pattern. It inherits the MarshalByValueComponent that does
have a finalize method and implements the IDisposable interface. But if you
look in the dataview's constructor it calls GC.SuppressFinalize since it
doesn't have any unmanaged resources, so there is no need to override the
dispose method. But it does override the dispose method which calls the
close method which does some unregistering of events from the datatable.

Actually if you look at the dataview, it implements an interesting pattern
with the datatable in question, its member dvListener (type of
dataviewlistener), the dataview itself, and weak references. I haven't been
able to study the whole pattern but it looks like even if the dataview's
dispose/close method isn't called, the dataview will still be GC'd because
the dvlistener actually registers to the datatables events and the
dvlistener has a weak reference back to the dataview to communicate the
events. Like I said I haven't looked at the whole pattern but it looks like
the dvListener will still be around registered to the datatable's events and
would still hang around but the dataview will be GC'd.


"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1b04c83673458e2698a871@msnews.microsoft.com...
> Chad Z. Hower aka Kudzu <cpub@hower.org> wrote:
> > Jon Skeet [C# MVP] <skeet@pobox.com> wrote in
> > news:MPG.1b04418d397844b498a868@msnews.microsoft.com:
> > > I disagree - in every case I can think of which I've come across,
> > > Dispose releases the resources that the finalizer would other do.
> >
> > It depends on how the resources are used and if the Dispose is a "Close"
or
> > not. But I guess in most cases it would be the same - but not all.
>
> Possibly not all, although I'd be interested to hear of an example.
> Have you heard of any?
>
> > > Why would you *want* to wait until the object is finalized before
> > > releasing resources if you've been explicitly told that the object
will
> > > no longer be used?
> >
> > In some cases the Dispose is more of a "Close" and shares code. But I
guess
> > that if it left resources too - that wouldnt be a commonly needed
situation.
>
> Indeed - and the fact that I can't think of a single situation where
> it's the case is fairly telling, I think.
>
> Certainly I believe that your statement that "This is not the case in
> most instances" (with regard to Dispose calling SuppressFinalize) in
> untrue. (The docs for Dispose even state: "However, once the Dispose
> method has been called, it is typically unnecessary for the garbage
> collector to call the disposed object's finalizer.")
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Re: IDisposable.Dispose, Object.Finalize and threads by Jon

Jon
Fri May 07 02:08:36 CDT 2004

JD <someone@somewhere.com> wrote:
> The dataview is the only class that I have seen that "kind of" does the
> close/dispose pattern. It inherits the MarshalByValueComponent that does
> have a finalize method and implements the IDisposable interface. But if you
> look in the dataview's constructor it calls GC.SuppressFinalize since it
> doesn't have any unmanaged resources, so there is no need to override the
> dispose method. But it does override the dispose method which calls the
> close method which does some unregistering of events from the datatable.

I don't see how that is quite what we were talking about. We were
talking about classes which implement IDisposable but which are still
finalized even is Dispose is called. The fact that SuppressFinalize is
called in the constructor instead of in Dispose is relatively
unimportant in this context - interesting though it certainly is.

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

Re: IDisposable.Dispose, Object.Finalize and threads by JD

JD
Fri May 07 04:36:15 CDT 2004

>>> I disagree - in every case I can think of which I've come across,
>>> Dispose releases the resources that the finalizer would other do.

>>It depends on how the resources are used and if the Dispose is a "Close"
or
>>not. But I guess in most cases it would be the same - but not all.

>Possibly not all, although I'd be interested to hear of an example.
>Have you heard of any?

I thought it may be relevant in the thread of conversation above. The
dataview dispose method does not release resources that the finalizer does.
In this case the finalizer is taken out of the picture right at the
construction of the object, dispose is merely a managed resource cleanup.
Sorry if 'm mistaken.


"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1b054651e1ebde1798a877@msnews.microsoft.com...
> JD <someone@somewhere.com> wrote:
> > The dataview is the only class that I have seen that "kind of" does the
> > close/dispose pattern. It inherits the MarshalByValueComponent that does
> > have a finalize method and implements the IDisposable interface. But if
you
> > look in the dataview's constructor it calls GC.SuppressFinalize since it
> > doesn't have any unmanaged resources, so there is no need to override
the
> > dispose method. But it does override the dispose method which calls the
> > close method which does some unregistering of events from the datatable.
>
> I don't see how that is quite what we were talking about. We were
> talking about classes which implement IDisposable but which are still
> finalized even is Dispose is called. The fact that SuppressFinalize is
> called in the constructor instead of in Dispose is relatively
> unimportant in this context - interesting though it certainly is.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Re: IDisposable.Dispose, Object.Finalize and threads by Daniel

Daniel
Fri May 07 06:29:28 CDT 2004

> Thats not correct.

Well, it is according to Microsoft's .NET Framework Developer's Guide topic
"Implementing a Dispose Method" available in Visual Studio Help:
"A Dispose method should call the GC.SuppressFinalize method for the object
it is disposing. If the object is currently on the finalization queue,
GC.SuppressFinalize prevents its Finalize method from being called. Remember
that executing a Finalize method is costly to performance. If your Dispose
method has already done the work to clean up the object, then it is not
necessary for the garbage collector to call the object's Finalize method."

In regards to the example code for the Dispose/Finalize pattern given:
"The Finalize method calls the Dispose method that takes parameters, passing
false. You should not re-create Dispose clean-up code within the Finalize
method"

Did that author not have any idea what he was talking about? It's not the
only place I've seen this pattern, BTW.

> Dispose and Finalize are not the same and in many cases you need both.
Of course. When did I suggest otherwise? In fact, I'd say you always
should include both, but ideally the Finalizer should never be needed.

>the Dispose you free the
> file handle, but in the Finalize you do it in case the user did not call
> Dispose.
Sounds pretty much like what I wrote, except I pointed out that these days
it is becoming pretty mainstream to consider the client not calling Dispose
as being a "bug", not just something oh well we'll clean up for him.



Re: IDisposable.Dispose, Object.Finalize and threads by Jon

Jon
Fri May 07 07:15:18 CDT 2004

Daniel Billingsley <dbillingsley@NO.durcon.SPAAMM.com> wrote:
> > Dispose and Finalize are not the same and in many cases you need both.
> Of course. When did I suggest otherwise? In fact, I'd say you always
> should include both, but ideally the Finalizer should never be needed.

You shouldn't always include both. If the class only deals with managed
resources (which may themselves contain unmanaged resources) you only
need a Dispose method.

StreamReader/StreamWriter is a good example of that - it includes a
Dispose method which calls Dispose on the underlying stream, but
there's no need to include a finalizer in it, as the stream itself will
have one if it needs it.

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

Re: IDisposable.Dispose, Object.Finalize and threads by David

David
Fri May 07 08:27:06 CDT 2004


"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1b058e36a2a3dca498a881@msnews.microsoft.com...
> Daniel Billingsley <dbillingsley@NO.durcon.SPAAMM.com> wrote:
> > > Dispose and Finalize are not the same and in many cases you need both.
> > Of course. When did I suggest otherwise? In fact, I'd say you always
> > should include both, but ideally the Finalizer should never be needed.
>
> You shouldn't always include both. If the class only deals with managed
> resources (which may themselves contain unmanaged resources) you only
> need a Dispose method.
>
> StreamReader/StreamWriter is a good example of that - it includes a
> Dispose method which calls Dispose on the underlying stream, but
> there's no need to include a finalizer in it, as the stream itself will
> have one if it needs it.

Also with purely managed resources, Dispose should sometimes be used to
prune dead objects from longer-lived objectcs which reference them.

For instance event consumers should unregister thier event handlers in
Dispose, making them elegible for GC sooner, but should not have a finalizer
because by the time the finalizer runs the whole tree has become
unreachable.

David



Re: IDisposable.Dispose, Object.Finalize and threads by Chad

Chad
Fri May 07 12:42:18 CDT 2004

Jon Skeet [C# MVP] <skeet@pobox.com> wrote in
news:MPG.1b04c83673458e2698a871@msnews.microsoft.com:
> Possibly not all, although I'd be interested to hear of an example.
> Have you heard of any?

I ran across some in preparing my sessions. I dont have them right now and I
have to leave tommorrow for the conference. They arent "most" as I stated
incorrectly before, but they do exist.

> Certainly I believe that your statement that "This is not the case in
> most instances" (with regard to Dispose calling SuppressFinalize) in
> untrue. (The docs for Dispose even state: "However, once the Dispose

Yes, the most was not a correct statement.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/