programacion metodo ejecutar asincrono asincrona c# .net asynchronous timeout delegates

c# - metodo - ¿Qué sucede si una llamada delegada asíncrona nunca vuelve?



ejecutar metodo asincrono c# (3)

Encontré un ejemplo decente de cómo llamar a un delegado de forma asíncrona con un tiempo de espera ... http://www.eggheadcafe.com/tutorials/aspnet/847c94bf-4b8d-4a66-9ae5-5b61f049019f/basics-make-any-method-c.aspx . En resumen, utiliza WaitOne con un tiempo de espera para determinar si la llamada no vuelve antes de que expire el tiempo de espera.

También sé que debe tener un EndInvoke para que coincida con cada BeginInvoke.

Entonces, ¿qué pasa si el tiempo de espera de espera expira? Nosotros (presumiblemente) NO queremos llamar a EndInvoke ya que se bloqueará. El código puede continuar haciendo "otras cosas", pero ¿hemos filtrado algo? ¿Hay algún hilo defectuoso en algún lugar bloqueado esperando una devolución que nunca sucederá? ¿Hemos filtrado algún recuerdo en el que se colocaría el resultado de esa voluntad de no retorno?


Creo que this post lo habla muy bien:

Desde el post:

No puede terminar un delegado asíncrono en ejecución si no es su hilo, pero puede hacerlo si lo es. Si usa los métodos comunes de tipo BeginInvoke, obtendrá un grupo de subprocesos administrados por el marco. Si usas la clase Thread (), obtienes tu propio hilo para administrar, iniciar, suspender, etc. a tu gusto.

El desarrollo asíncrono requiere que uno decida quién manejará los hilos. Los muchos métodos diferentes que se ejecutan de forma asíncrona están utilizando los hilos de ThreadPool detrás de escena.

Como no puede / no debe terminar un subproceso de grupo de subprocesos, debe diseñar su código para comunicarse con el subproceso para que pueda salir. Los ejemplos de MSDN para el componente BackgroundWorker demuestran este tipo de comunicación.

A veces, su código puede tener el bloqueo del hilo esperando a IO. En este caso, normalmente usaría una espera de múltiples objetos, esperando IO o un ManualResetEvent.

En resumen, deberá encontrar una forma de administrar los subprocesos usted mismo si existe la posibilidad de que se agote el tiempo de espera y desea que el subproceso finalice.


Necesitas llamar a EndInvoke ().

Aquí hay un enlace que habla sobre lo que sucede con EndInvoke ():

¿EndInvoke () es opcional, algo así como opcional, o definitivamente no es opcional?

Aquí hay un link al artículo en la respuesta aceptada.

Todos habíamos estado hablando sobre la técnica de "disparar y olvidar" con la invocación asíncrona de delegados en varios foros públicos. Muchos instructores de DevelopMentor habían escrito artículos y código de ejemplo que mostraba la técnica, y todos lo habíamos descrito en clase. Y, por supuesto, también estaba en el libro de Don. Entonces, cuando Microsoft finalmente recordó dejarle saber al mundo exterior que esta técnica no es, de hecho, legal, fue bastante sorprendente.

Un link MSDN en el patrón asíncrono.


Va a filtrar los recursos en poder del hilo. Habrá varios bits de objetos de plomería remotos .NET como el AsyncResult. Varios manejadores no gestionados asociados con el hilo. Todos los cacahuetes comparados con el megabyte de espacio de direcciones de memoria virtual que perderá, retenido por la pila de hilos.

No puedes abortar el hilo de ninguna manera, la fuga es permanente. Cuando tienes que lidiar con un código de mal comportamiento como este, tu único buen recurso es ejecutarlo en un proceso separado para que Windows pueda limpiar la metralla cuando dispares el proceso en la cabeza con Process.kill (). Incluso eso no está garantizado, este tipo de congelaciones tienden a asociarse con el mal comportamiento de los controladores de dispositivos. Process.Kill no terminará un subproceso de controlador de dispositivo. Fácil de ver: intentar abortar el proceso con Taskmgr.exe lo dejará ejecutándose con una sola manija. Tienes algo de esperanza si eso no sucede.