3

This post says that when you call the BeginInvoke method on a delegate, it is always necessary to call the EndInvoke method. Another post backs it up and suggests the class BackgroundWorker as an alternative.

I used ILSpy to decompile BackgroundWorker and I have found out that actually, EndInvoke is never called in this class, even though it does use BeginInvoke on a delegate.

Does this mean that BackgroundWorkder is ill-implemented, or is calling EndInvoke not so necessary after all?

(The issue with exceptions being lost is irrelevant, since the whole method being invoked is enclosed in a try-catch block)

On a similar matter: it there a clear reason why BeginInvoke was chosen in implementation of BackgroundWorker over say, ThreadPool.QueueUserWorkItem()?

Edit: the source code of BackgroundWorker can be viewed here.

Community
  • 1
  • 1
Martin
  • 189
  • 1
  • 7

1 Answers1

1

I looked for the man-behind-the-curtain for a while. The CLR has secret knowledge of the SynchronizationContext class so technically it could be involved here. Found absolutely nothing.

Until I checked what I should have done in the first place, actually verify the claim that EndInvoke() is required:

using System;

class Program {
    static void Main(string[] args) {
        Action d = null;
        d = new Action(() => {
            d.BeginInvoke(null, null);
        });
        d();
        Console.ReadLine();
    }
}

Runs like gangbusters and consumes plenty of handles. But it won't blow up, they never go over ~2000 and memory usage is completely stable.

So perhaps it is appropriate to tweak the claim that calling a delegate's EndInvoke() is required. If you have a priori knowledge that the delegate target will not doing anything unusual, like calling into another AppDomain, running native code or activate remoted code then you can get away with not calling EndInvoke(). A guarantee that BackgroundWorker can provide. I can never make that claim stick as just a mere SO user. But Microsoft does it so it must be okay. A comment in the source code would have been nice.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • FWIW: I don't have a link handy, but I researched this question about a decade ago, and remember finding Microsoft-sanctioned references that described both the delegate and `Control`'s `EndInvoke()` methods as optional. I am surprised by the MSDN reference that apparently contradicts at least the delegate scenario reference I found earlier (but it seems that particular reference had that advice as far back as .NET 2.0). Of course, calling `EndInvoke()` is important if you actually want to receive the return value of the invoked delegate, so there's that. :) – Peter Duniho Feb 21 '15 at 01:51