It would be nice, at this point, that Delegate-derived classes was not sealed. Now I need a wrapper class to encapsulate a delegate ensuring a call to EndInvoke when it is necessary... But it would be really a risk calling that inside a IDisposable pattern: imagine what happen if someone forget to call Dispose and the Finalize try to call EndInvoke... It seems not a very good idea...
It really sucks. I can live with it, but I'd like to know why they chosed so. Marco -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Woodring (DevelopMentor) Sent: sabato 15 febbraio 2003 1.01 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] delegate vs threadpool > Just to add a result from a little test program I wrote: there is no > evidence of any memory/resource leak. Even calling 1.000.000 > BeginInvoke on many Delegate. No matter what your tests (and mine) show, the fact is that the runtime team has "reserved the right" to leak if you don't call EndInvoke. They've stated this in support calls and have taken explicit steps in the 1.1 SDK to document that calling EndInvoke is required. The result is that just because your code isn't leaking detectably today doesn't mean it might not start leaking on a future version/service-pack of the runtime. If the docs say you must call EndInvoke (which they do starting with the 1.1 docs), then anyone not calling EndInvoke is doing so at their own risk. By putting the explicit mandate in the docs, the runtime has eliminated any liability on their part if applications that don't call EndInvoke start to experience leaks/problems. It will be our fault instead of theirs. It sucks, but there you have it. -Mike DevelopMentor http://staff.develop.com/woodring
