1

Possible Duplicate:
Why does asynchronous delegate method require calling EndInvoke?
Is Delegate.EndInvoke() really necessary?

Working on a multi-threaded application at the moment and when raising an event instead of doing the normal handler.Invoke(); I am experimenting with handler.BeginInvoke();. Both work fine. However, for BeginInvoke I am using null for the last two arguments because there needs not be a callback and since there is no callback, there is definitely no need for data to be passed to a non-existent callback.

Because of this, I am not calling EndInvoke at all. But the application seems to.. work perfectly? I read and people said there would be leaks which may be occurring but I am just not noticing.

I'm curious though, what exactly does EndInvoke do? Do I really need to make a callback just to call EndInvoke and that's it? Also, why does EndInvoke take an IAsyncResult argument? I can just pass null for that right because there is no extra data being passed to the callback, correct? But still, I'm wondering, why, if there was extra data, would it need to be passed to EndInvoke? What is it doing with that parameter? I want to know how it works.

I checked the .NET Reflector but I couldn't find where EndInvoke was actually defined. In EventHandler (which is what I'm using) all it showed was the method header.

Thanks.

Community
  • 1
  • 1
Ryan Peschel
  • 11,087
  • 19
  • 74
  • 136
  • [The answers in this EndInvoke question](http://stackoverflow.com/q/532722/238688) don't address everything asked here, but should provide *some* extra insight. – Dan J Sep 26 '11 at 17:13
  • cf. also http://stackoverflow.com/questions/1712741/why-does-asynchronous-delegate-method-require-calling-endinvoke – jason Sep 26 '11 at 17:13

3 Answers3

5

The main practical concerns are deterministically cleaning up a wait handle resource (if you chose to create the handle by referencing it) and making sure that Exceptions are propagated properly.

That said, what I would recommend is to move away from the slightly schizophrenic asynchronous pattern in the earlier .NET framework and use TPL, which has a much cleaner continuation model. The TPL even has some nice wrapping functionality to help deal with the older Begin/End style of calling:

http://msdn.microsoft.com/en-us/library/dd997423.aspx

Dan Bryant
  • 27,329
  • 4
  • 56
  • 102
  • Didn't get the part about creating wait handle resource. Could you please clarify? Maybe with an example. Thanks! – Yola Dec 11 '18 at 18:32
  • 1
    @Yola, The `IAsyncResult` has an `AsyncWaitHandle` property that, when referenced, creates a wait handle. This is an OS-level resource and needs to be cleaned up when you're no longer using it, but the Begin/End style async calls cannot release the wait handle until you confirm you're no longer using it by calling End. This isn't strictly required if you never reference the handle. All that said, this older style (and even the TPL style I reference above) are largely deprecated in favor of using async/await these days. – Dan Bryant Dec 11 '18 at 21:12
2

As was mentioned in one of the referenced articles, if you're invoking a delegate in a fire-and-forget fashion, you probably should use ThreadPool.QueueUserWorkItem instead. Then you won't have to worry about cleaning up with EndInvoke.

Corey Kosak
  • 2,615
  • 17
  • 13
1

According to MSDN, you ought to always call EndInvoke no matter what:

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

So take that for what it's worth. I assume it's futureproofing.

mqp
  • 70,359
  • 14
  • 95
  • 123
  • Yes I saw that before posting this. I'd really like to know what it does under the hood, though. *Why* is it necessary to always call, because according to Jon Skeet you don't have to call EndInvoke for Control types. Why is this? – Ryan Peschel Sep 26 '11 at 17:20
  • `delegate.EndInvoke()` and `Control.EndInvoke()` are completely different. – Dour High Arch Sep 26 '11 at 19:41