> > That said, one difference that's recently come to light is > > that the .NET 1.1 sdk docs have introduced a new caution > > stating that EndInvoke must be called after using BeginInvoke > > in order to avoid leaking things [1]. > > This is a real shame. I've used BeginInvoke in a fire-and-forget type > way and it's pretty damn useful. If they're going to introduce a > warning that it could be a problem, I feel they should implement a > "FireAndForget" type function, like you have in your > AsyncHelper. That > would make things clearer to the casual developer.
I agree. > > What's the point of a garbage collector if it won't solve > these leakage > issues? I think it issue is that Delegate.BeginInvoke isn't really a managed method per-se, it's synthesized on the fly by the runtime when a given delegate type is loaded. And this implementation presumably uses some native resources to do its job, so the call to EndInvoke lets them release this stuff. But this is all conjecture. I've looked at the Rotor sources to get a sense for what BeginInvoke looks like as generated on the fly, but it's not the simplest piece of code to decipher, so I'm still digesting... > > Incidentally, does the same requirement to call EndInvoke > exist when you > do a .BeginInvoke on a windows form control? > I have heard that the answer to that is "yes", although my look at the implementation of Control.BeginInvoke & EndInvoke doesn't make the reason so obvious. Control.BeginInvoke, unlike Delegate.BeginInvoke, is mostly just posting something to a target windows message queue. And Control.EndInvoke just blocks the caller if the request hasn't been processed yet. If the method has already completed when you call EndInvoke, it just returns the return value. In neither case does it do any kind of apparent resource cleanup. And the 1.1 .net sdk docs for Control.BeginInvoke do not carry the same caution that the docs for Delegate.BeginInvoke do. So personally, I'd be inclined to just keep using Control.BeginInvoke in a fire-and-forget pattern until I've quantified an actual problem with it, or until I move to a non-windows platform underneath the CLR. But that's just me. If you go strictly by the docs, it's ambiguous whether or not Control.EndInvoke is required. -Mike DevelopMentor http://staff.develop.com/woodring
