2009-10-29 8 views
5

Una pregunta asincrónica:EndInvoke() - ¿opcional o no?

He estado leyendo en Internet MUCHOS artículos a favor y en contra de Delegate.EndInvoke() es opcional. La mayoría de esos artículos tienen entre 4 y 5 años. Muchos enlaces muertos

¿Alguien puede explicar, en .NET 2.0 - es que EndInvoke() de hecho previene una fuga de memoria inevitable, y en caso afirmativo, puede especificar qué causa esta fuga?

Sobre el mismo tema: si EndInvoke() es de hecho una necesidad - encuentro la mejor manera de implementar el mecanismo de "olvidar y olvidar" usando un método de devolución de llamada que ejecuta EndInvoke(). Me encantaría saber de alguien que piense lo contrario.

Gracias, O

Respuesta

8

Para Delegate.EndInvoke, que debe llaman. Para Control.EndInvoke, el equipo de WinForms ha dicho que no necesita para llamarlo. No sé sobre el equivalente para WPF, pero creo que es una buena idea hacerlo a menos que tengas una realmente buena razón para creer que no tienes que hacerlo.

Tengo un código de "disparar y olvidar" para los delegados en mi threading article - aproximadamente a mitad de camino (busque "fuego").

+0

¿Cuál es el significado de fire-n-forget? Asumía que: 1) Si haces un BeginInvoke y no utilizas ningún sondeo, manipuladores de espera o devolución de llamada, entonces se trata de un método de fuego-n-forget 2) Solo se pueden usar métodos de retorno nulo para fire-n-forget para que no necesites preocuparse por usar cualquiera de los tres anteriores después de hacer un BeginInvoke. Creo que si sugieres utilizar la devolución de llamada para evitar fugas de memoria, ya no es Fire-n-forget. –

+0

Esa fue exactamente mi pregunta. Si la guía es usar siempre EndInvoke(), entonces no hay opción para disparar y olvidar. Un poco extraño. – tsemer

5

Desde el msdn:

Siempre llame EndInvoke para completar su llamada asincrónica.

Te aconsejo que sigas las instrucciones, incluso si funciona hoy sin fugas, puede cambiar mañana.

Cuestiones relacionadas