是否存在诸如Thread.OnAborting()之类的事件? [英] Does some event like Thread.OnAborting() exist?

问题描述

环境:

假设我有一个主要应用程序，

Let's say I have a main application that:

• 听任务请求，
• 一个接一个地执行那些任务(使用一些资源(在物理意义上))，
• 必须能够立即停止待处理的任务以处置资源.

• Listen for requests for tasks to do,
• Perform those tasks (that use some resources (in a physical meaning)) one after another,
• Must be able to instantly stop a pending task to dispose the resources.

我有两个计时器:

• 在timer1勾上，应用程序正在检索新请求并将其存储在Queue中，
• 在timer2勾上，应用程序将请求出队，以在新的Thread中执行任务.

• On the timer1 tick, the application is retrieving new requests and store them in a Queue,
• On the timer2 tick, the application is dequeueing a request to perform the task in a new Thread.

当用户要求停止所有任务以释放资源时，我计划使用

When a user ask to stop all tasks to have the resources free, I plan to simply kill the thread running the current task with Thread.Abort().

问题:

从线程类中杀死线程时，我希望能够保存一些最后的配置.

I would like to be able to save some last configuration when killing the thread from the thread class.

问题:

是否有一种方法可以检测线程何时被杀死，例如Thread.OnAborting()事件?

Is there a way to detect when the thread is killed, like a Thread.OnAborting() event?

或者我可以抓住 ThreadAbortException 在调用Thread.Abort()方法时引发? (如果是这样，我真的不知道该怎么做，您能提供一些代码示例吗?)

Or maybe could I catch the ThreadAbortException raised when calling the Thread.Abort() method? (if so, I don't really know how to do it, could you provide some code example?)

推荐答案

除了捕获ThreadAbortException之外，没有其他机制.当然，您实际上绝对不想调用Thread.Abort，因为ThreadAbortException是异步注入的，并且这些注入点可能是不可预测的.例如，它可能在写入过程中，可能会使整个AppDomain处于损坏状态. .NET 2.0添加了受约束的执行区域，这使得处理线程异常终止更安全，更容易处理，但是难以置信编写一段可以保证AppDomain不会损坏的代码仍然很困难.我的建议是提倡Thread.Abort想法.

Other than catching the ThreadAbortException no other mechanism exists. Of course, you really do not want to be calling Thread.Abort anyway because the ThreadAbortException gets injected asynchronously and those injections points can be unpredictable. For example, it could be in the middle of a write which might leave the entire AppDomain in a corrupted state. .NET 2.0 added constrained execution regions which makes dealing with thread aborts a lot safer and easier to handle, but it is still incredibly difficult to author a block of code that can guarantee that the AppDomain will not get corrupted. My advice is to punt on the Thread.Abort idea.

相反，您要执行的操作是向线程发送信号，并允许它自己优雅地终止.这可以通过以下机制来完成.

Instead what you want to do is send a signal to the thread and allow it terminate gracefully on its own. This can be done with the following mechanisms.

• 投票标志
• 使用等待句柄
• 致电Thread.Interrupt
• 使用长期运行的API中内置的取消机制

• Poll a flag
• Use wait handles
• Call Thread.Interrupt
• Use the cancellation mechanisms built into the APIs of long running operations

您可以在此处了解更多信息.

You can see my answer here for more information.

这篇关于是否存在诸如Thread.OnAborting()之类的事件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！