views:

148

answers:

2

Hi all,

An asynchronous question:

I've been reading over the internet LOTS of articles for and against Delegate.EndInvoke() being optional. Most of those articles are 4-5 years old. Lots of dead links.

Can anyone explain, in .NET 2.0 - is EndInvoke() indeed preventing an otherwise-inevitable memory leak, and if yes can you please specify what causes this leak?

On the same subject: If EndInvoke() is indeed a must - I find the best way to implement Fire-and-forget mechanism using a callback method that runs EndInvoke(). I'd love to hear from anyone who thinks otherwise.

Thanks, O

+3  A: 

For Delegate.EndInvoke, you should call it. For Control.EndInvoke, the WinForms team has said that you don't need to call it. I don't know about the equivalent for WPF, but I think it's a good idea to do so unless you've got a really good reason to believe you don't have to.

I have some "fire and forget" code for delegates in my threading article - about half way down (search for "fire").

Jon Skeet
What is the meaning of fire-n-forget? I was assuming: 1) If you do a BeginInvoke and use neither polling, wait handles or callback, then it's a fire-n-forget method 2) Only void return methods can be used for fire-n-forget so that you need not worry about using either three of the above after doing a BeginInvoke. I think if you suggest to use callback to avoid memory leaks, its not fire-n-forget anymore.
Rashmi Pandit
That was exactly my question. If the guideline is to always use EndInvoke() then there is no option for fire-and-forget. A bit strange.
tsemer
+2  A: 

From the msdn :

Always call EndInvoke to complete your asynchronous call.

I advice you to follow the guidelines, even if it works without leaks today, it may change tomorrow.

Guillaume