Is EndInvoke() optional, sort-of optional, or definitely not optional?

C#MultithreadingDelegates

C# Problem Overview


I've read conflicting opinions as to whether every BeginInvoke() has to be matched by an EndInvoke(). Are there any leaks or other problems associated with NOT calling EndInvoke()?

C# Solutions


Solution 1 - C#

Delegate.EndInvoke is documented as a thou shalt call this (i.e. necessary - else leaks happen) - from msdn:

> Important Note > > No matter which technique you use, > always call EndInvoke to complete your > asynchronous call.

Control.EndInvoke is OK to ignore for fire-and-forget methods - from msdn:

> You can call EndInvoke to retrieve the > return value from the delegate, if > neccesary, but this is not required.

However - if you are using Delegate.BeginInvoke and don't want the result, consider using ThreadPool.QueueUserWorkItem instead - it'll make life a lot easier, and avoid the pain of IAsyncResult etc.

Solution 2 - C#

EndInvoke is not optional.

More info here

Solution 3 - C#

And EndInvoke call is not optional call, it is a part of the contract. If you call BeginInvoke you must call EndInvoke.

Classic example of why this is necessary. It's very possible that the IAsyncResult returned from BeginInvoke has allocated resources attached to it. Most commonly a WaitHandle of sorts. Because IAsyncResult does not implement IDisposable another place must be chosen to free the resources. The only place to do so is EndInvoke.

I briefly discuss this problem in the following blog post.

http://blogs.msdn.com/jaredpar/archive/2008/01/07/isynchronizeinvoke-now.aspx

Solution 4 - C#

EndInvoke is not optional because it is the place where exceptions are thrown if something went wrong in the asyncronous processing.

Anyway there should not be any leak because if the IAsyncResult is holding some native resource it should correctly implement IDisposable and dispose such resources when the GC calls his finalizer.

Solution 5 - C#

It is not optional because calling BeginInvoke makes use of a WaitHandle which in turns makes use of a kernel object that maintains a count for how many references are had to it. Calling EndInvoke gracefully disposes the handle which decrements that counter on the kernel object and when that count reaches zero, the kernel object manager will destroy it.

Solution 6 - C#

Its only optional if you don't mind your program's memory growing very large. The issue is that the GC is holding onto all of the references in your thread, because you might want to call EndInvoke at some point. I would go with Marc's answer, the threadpool will make your life easier. However, you need to watch out if you spawn threads from your threads, as it is limited in the number of threads it can spin up.

Solution 7 - C#

Every reply on this post says that EndInvoke() is not optional. However, I found the following highly ranked comment that is the accepted answer on this SO thread:

"Note that the Windows Forms team has guaranteed that you can use Control.BeginInvoke in a 'fire and forget' manner - i.e. without ever calling EndInvoke. This is not true of async calls in general: normally every BeginXXX should have a corresponding EndXXX call, usually in the callback."

https://stackoverflow.com/questions/229554/whats-the-difference-between-invoke-and-begininvoke

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionendianView Question on Stackoverflow
Solution 1 - C#Marc GravellView Answer on Stackoverflow
Solution 2 - C#Luca MartinettiView Answer on Stackoverflow
Solution 3 - C#JaredParView Answer on Stackoverflow
Solution 4 - C#MaghisView Answer on Stackoverflow
Solution 5 - C#James AlexanderView Answer on Stackoverflow
Solution 6 - C#SteveView Answer on Stackoverflow
Solution 7 - C#Robert OschlerView Answer on Stackoverflow