Re: Garbage collection and async operations

Tech-Archive recommends: Fix windows errors by optimizing your registry

So if I really don't care about the result of the asynchronous operation
(including any exception that it may have thrown) then nothing bad happens
if I don't call EndInvoke. (My actual application has a Cancel method on
the class containing the long-running async operation. But cancellation may
take a while. So after I call Cancel I just get rid of my reference to the
object and assume that it will eventually stop running and the GC will
eventually collect it.)

Thanks a million for helping me understand this!

- Bob

"Jon Shemitz" <jon@xxxxxxxxxxxxxxxxx> wrote in message
news:456F593E.ADF5837E@xxxxxxxxxxxxxxxxxxxx
Bob Altman wrote:

1. If I call a delegate's BeginInvoke method then the invoked routine
will
run to compltion on a thread pool thread, regardless of whether or not
that
routine or its delegate goes out of scope.

Yes.

2. When the background routine completes, its thread pool thread may or
may
not be assigned some other work, or that thread may be terminated. This
mechanism is independent of whether or not I call EndInvoke.

Yes.

3. If the Delegate goes out of scope before I call EndInvoke then I leak
the
Delegate (which presumably holds the return value from the invoked
routine
and the Exception object thrown by the invoked routine). Specifically,
some
magic in the CLR keeps the Delegate alive until its EndInvoke method is
called.

No. The return value or exception are stored in the object that
implements IAsyncResult. (Think about it: Many (most?) delegates are
never executed asynchronously. The IAsyncResult is explicitly created
by the runtime when you call BeginInvoke. The IAsyncResult must be
passed to EndInvoke. Where would *you* put the result?)

On a tangentially related subject: Is there a memory leak if I call a
Control object's BeginInvoke method (to run a routine on the UI thread)
and
never call the Control's EndInvoke method? Specifically, I use this code
pattern for handling events that may be raised on another thread:

No. This is explicitly documented as safe.

--

.NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.


.

Relevant Pages

  • Re: Garbage collection and async operations
    ... memory leaks EXCEPT Control.BeginInvoke. ... resources if EndInvoke is not called. ... routine or its delegate goes out of scope. ... Delegate (which presumably holds the return value from the invoked ...
    (microsoft.public.dotnet.framework)
  • Re: Keine Ausnahme bei BeginInvoke ohne EndInvoke
    ... public delegate void Foo; ... die in Bar() ausgelöst wird? ... Der Aufruf von asyncronen Delegates cached die Exception, ... Dazu brauchst Du eben das EndInvoke. ...
    (microsoft.public.de.german.entwickler.dotnet.framework)
  • Re: exception handling with events
    ... You must call EndInvoke to avoid memory leaks. ... The good news is that any exception that your DoAction threw will be ... Of course you need the delegate to fire EndInvoke. ... // the exception thrown by Server.DoAction ...
    (microsoft.public.dotnet.languages.csharp)
  • Looking for advice on a robust TCP/IP client implementation
    ... exception is encountered. ... additional data needs to be sent back via the socket, ... /// Event delegate to use for the connection and disconnection ... public delegate void ConnectionEventHandler(object sender, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: BeginInvoke without EndInvoke allowed?
    ... harm in not calling Control.EndInvoke, I would say that absent some clear, explicit statement in the MSDN documentation pages that says that you don't need to call EndInvoke, that pairing the two calls may well be important, and very much _should_ be assumed to be so, ... And with our knowledge of MSDN, even present some clear, explicit statement might not be enough either. ... EndInvoke would impose an unnecessary delay on the background thread where I call BeginInvoke. ... If you call Delegate.BeginInvoke() on the delegate instance itself, ...
    (microsoft.public.dotnet.framework)