¡Muere el hilo, realmente!

Necesito terminar un hilo congelado, configuré IsBackground como verdadero pero permanece vivo. propiedades del hilo:¡Muere el hilo, realmente!

ThreadState = AbortRequested

IsBackground = true

Cuando examino el congelado del punto encuentro la línea de abajo:

resultDetect = Detect(input, ref output);

El spot es una tercera parte código (método de detección). El hilo solo actualiza resultado. Detecta como ves. Necesito abortar ese hilo y reiniciar uno nuevo para continuar. De lo contrario, la aplicación espera y no hace nada -resultado nuevoDetección necesaria-

¿Cómo puedo eliminar el hilo que no muere?

Fuente

2011-07-25 Nime Cloud

Solo hay una forma de eliminar de forma segura un hilo colgado en su aplicación: Environment.Exit Y hasta eso puede fallar si el hilo ejecuta el código kernel.

Es mejor no utilizar código de terceros que se cuelga. Si no tiene otra opción, ejecútelo en un proceso separado.

Fuente

2011-07-25 12:48:16

Esto ya está en el lado del servidor del código. El método escanea una gran cantidad de datos (~ 1GB de RAM). ¿Cómo puedo comenzar un nuevo proceso de manera súper rápida? Supongamos que dividiré el servidor en la sección base/memoria y exploraré la sección ... Así puedo matar la sección de escaneo. Creo que voy a hacer una nueva pregunta. –

@Nime: no hay suficientes detalles para continuar, pero mencionaré que el ['MemoryMappedFile'] (http://msdn.microsoft.com/en-us/library/system.io.memorymappedfiles.memorymappedfile. aspx) class permite compartir memoria entre procesos, por lo que esta es una forma rápida de otorgar acceso de solo lectura al proceso de escaneo a un conjunto de datos sin dejar de ser capaz de matarlo independientemente del proceso principal. –

Quizás intente llamar al Thread.Abort(). Aunque no se recomienda (Consulte Killing a .NET thread)

Fuente

2011-07-25 12:48:30 marc

Lo intento en un temporizador ... No ayuda. –

Si Detect hace una transición al código no administrado, el CLR pospondrá la inyección del ThreadAbortException hasta que vuelva. Este comportamiento cambió en .NET 2.0 para hacer que el aborto de subprocesos sea mucho más seguro. El CLR está tratando realmente de protegerlo de corromper el estado del proceso, que sería muy probable en el caso de un código no administrado, ya que no obtiene el beneficio del aislamiento de los dominios de la aplicación que pueden descargarse fácilmente en un escenario totalmente administrado. . En realidad, la única solución es ejecutar esta API en un proceso separado y usar WCF, comunicación remota, etc. para comunicarse con ella.

Fuente

2011-07-25 12:51:14

Respuesta

Cuestiones relacionadas