Menu
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
402
As a matter of practice, you should call EndInvoke because the caller may have handlers subscribed to the events that may not matter to your processing, but may matter to the consumer so as to ensure certain kinds of processing can take place at a known time/application state.
The EndInvoke method retrieves the results of the asynchronous call and releases the resource used by the thread. The parameters of EndInvoke include the out and ref parameters of the method that you want to execute asynchronously, plus a reference to the IAsyncResult returned by the BeginInvoke.
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").
177
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
