Partekatu honen bidez:

Destrucción de subprocesos

Para finalizar la ejecución del subproceso, normalmente se usa el modelo de cancelación cooperativa. Sin embargo, a veces no es posible detener un subproceso de forma cooperativa, ya que ejecuta código de terceros no diseñado para la cancelación cooperativa. En las aplicaciones de .NET Framework, puede usar el Thread.Abort método para finalizar un subproceso administrado forzosamente. Cuando se llama a Abort, Common Language Runtime inicia un ThreadAbortException elemento en el subproceso de destino, que el subproceso de destino puede detectar. (Sin embargo, el entorno de ejecución de .NET Framework siempre vuelve a generar automáticamente la excepción después del bloque catch). Para obtener más información, vea Thread.Abort.

El método Thread.Abort lanza una PlatformNotSupportedException en tiempo de ejecución en .NET Core y .NET 5 y versiones posteriores. A partir de .NET 5, también está marcado como obsoleto (SYSLIB0006), por lo que llamarlo genera una advertencia en tiempo de compilación. Si necesita finalizar la ejecución de código de terceros forzadamente en implementaciones modernas de .NET, ejecútelo en el proceso independiente y use Process.Kill.

Nota:

  • Cuando llamas a Thread.Abort para anular un subproceso distinto del subproceso actual, no sabes qué código se ha ejecutado o ha fallado al ejecutarse cuando se lanza ThreadAbortException. Tampoco puede estar seguro del estado de su aplicación, ni de cualquier estado de aplicación o usuario que deba preservar. Por ejemplo, llamar Thread.Abort puede impedir la ejecución de constructores estáticos o la liberación de recursos administrados o no administrados.
  • Si un hilo ejecuta código no gestionado cuando se llama a su Abort método, el tiempo de ejecución ThreadState.AbortRequested marca lo. La excepción se lanza cuando el hilo vuelve al código administrado.

Una vez anulado un subproceso, no se puede reiniciar.

El método Abort no hace que el subproceso se interrumpa inmediatamente, ya que el subproceso de destino puede capturar ThreadAbortException y ejecutar cantidades arbitrarias de código en un bloque finally. Puede llamar Thread.Join si necesita esperar hasta que finalice el hilo. Thread.Join es una llamada de bloqueo que no devuelve hasta que el subproceso realmente ha dejado de ejecutarse o ha transcurrido un intervalo de tiempo de espera opcional. El subproceso anulado podría llamar al método ResetAbort o realizar un procesamiento ilimitado en un bloque finally, por lo que si no especifica un tiempo de espera, no se garantiza que finalice la espera.

Los subprocesos que están esperando en una llamada al método Thread.Join pueden ser interrumpidos por otros subprocesos que llaman a Thread.Interrupt.

Manejo de ThreadAbortException

Si espera que se aborte el subproceso, ya sea como resultado de llamar a Abort desde su propio código o como resultado de descargar un dominio de aplicación en el que se ejecuta el subproceso (AppDomain.Unload utiliza Thread.Abort para terminar subprocesos), el subproceso debe manejar ThreadAbortException y realizar cualquier procesamiento final en una cláusula finally, como se muestra en el código siguiente.

Try  
    ' Code that is executing when the thread is aborted.  
Catch ex As ThreadAbortException  
    ' Clean-up code can go here.  
    ' If there is no Finally clause, ThreadAbortException is  
    ' re-thrown by the system at the end of the Catch clause.
Finally  
    ' Clean-up code can go here.  
End Try  
' Do not put clean-up code here, because the exception
' is rethrown at the end of the Finally clause.  

try
{  
    // Code that is executing when the thread is aborted.  
}
catch (ThreadAbortException ex)
{  
    // Clean-up code can go here.  
    // If there is no Finally clause, ThreadAbortException is  
    // re-thrown by the system at the end of the Catch clause.
}  
// Do not put clean-up code here, because the exception
// is rethrown at the end of the Finally clause.

El código de limpieza debe estar en la catch cláusula o en la finally cláusula, porque un ThreadAbortException se relanza por el sistema al final de la finally cláusula o al final de la catch cláusula si no hay ninguna finally cláusula.

Puede impedir que el sistema vuelva a lanzar la excepción llamando al Thread.ResetAbort método. Sin embargo, solo debe hacer esto si su propio código provocó el ThreadAbortException.

Consulte también

  • Last updated on