2009-08-13 13 views
25

This page in the MS documentation, cubriendo asincronía en aplicaciones Windows Forms, afirma:¿Debe cada BeginInvoke ir seguido de un EndInvoke?

Puede llamar EndInvoke para recuperar el valor de retorno del delegado, si NECESARIO, pero esto no es necesario. (énfasis añadido)

This page covering the general case of asynchronous delegates, indica algo diferente:

No importa la técnica que utilice, siempre llame EndInvoke para completar su llamada asincrónica.

Estos dos parecen estar en conflicto directo.

¿Cuál es la verdad? ¿Alguien puede explicar?

vea también, a post by Phil Haack.

relacionadas: Is EndInvoke optional, sort-of optional, definitely not optional?

Respuesta

22

A menos que la documentación de una interfaz indique explícitamente lo contrario, debe llamar a EndInvoke para cada lugar al que llame BeginInvoke. La razón principal es que EndInvoke es el único momento en que el propietario puede liberar de forma segura ciertos recursos que pueden asignarse para la llamada a BeginInvoke (como un WaitHandle).

Pero hay excepciones a esta regla. Las API como Control.BeginInvoke no requieren un EndInvoke pero es explícito en la documentación.

13

Ambas cosas son ciertas - son diferentes llamadas.

En general siempre debe llamar EndInvoke para asegurar que todos los recursos adquiridos por la llamada asincrónica son liberados.

Sin embargo, el equipo de Windows Forms ha garantizado que no necesita hacer esto para Control.Invoke. Puede que necesite hacerlo para otras implementaciones de ISynchronizeInvoke.

+0

Estoy de acuerdo con la mayoría de su respuesta, excepto el comentario de que son "llamadas diferentes". No parecen ser llamadas diferentes en absoluto. ¿No están discutiendo EndInvoke sobre los delegados de Asynch? Es solo que EndInvoke en los delegados de control es un caso especial. – Cheeso

+3

@ Cheeso: No - Control.BeginInvoke no es una llamada * en * un delegado en absoluto. * Toma * un delegado. –

1

He usado el método de "olvídate del fuego" con los delegados antes de que los resultados fueran "útiles si están disponibles, pero no son obligatorios". Solo recuerda que no tienes garantías de finalización con ese método. En particular, esto es un lugar que lo uso:

  • Comenzar un delegado para comprobar si hay actualizaciones de la aplicación
  • Delegado inicia una petición web con un tiempo de espera
  • Si se produce un error/tiempo de espera, o si la solicitud es hasta a la fecha, el método simplemente devuelve
  • Si la aplicación no está actualizado, coloco una (sin icono de la bandeja del sistema a menos que la actualización está disponible) no enfoque de robo de mensaje de la bandeja del sistema indicando así que

De cualquier manera, th La aplicación continúa ininterrumpida.

Cuestiones relacionadas