C# 为什么不支持中断任务？
C# Why is interrupting a Task not supported?
线程支持中断。为什么没有任务？
从我（不知情的）角度来看，允许 Task 支持中断似乎是合理的：
- 如果任务当前未在线程上执行，则调用 task.Interrupt() 将设置一个 TaskInterruptException，以便在安排任务时抛出该异常。
- 否则，TaskInterrupException 将在执行任务的线程中抛出，该异常将在任务中捕获或添加到顶部的 AggregateException。我想这个功能需要任务知道正在执行的线程（这不合理吗？）
实现此功能所需的部分是否已经存在，或者这是否需要更改语言实现？
加法：
我已经阅读了许多关于讨论 killing/aborting 任务的问题，以及讨论 CancellationToken 和（气馁）Thread.Abort 方法的相关答案。
在我自己的摆弄中，我发现用CancellationToken.Register注册Thread.Interrupt并不会中断任务中的线程运行，而是中断在token上调用cancel的线程.
因此，在我看来，仍然需要允许开发人员确保可以（温和地）终止任务的认可功能。
我还要补充（以免有人说 "re-write your Tasks to take CancellationTokens"）在开发人员 不 拥有任务中正在执行的代码的情况下，此功能特别有价值.
而且，从原则上讲，似乎应该有一种方法让任务的执行者能够提供取消的保证，而不是依赖于任务的实施者来正确地做事取消令牌。
另加：
不管风险如何，C# API 支持 Thread.Abort 和 Thread.Interrupt。所以我的问题是，本质上，为什么 Task 不支持相同的 API（具有相同的固有风险）？
更新
此 post 已被标记为 this question. However, I had already read the referenced question before posting this one (and all of the answers) - this question is not a duplicate, but a related question seeking additional information. That question asks "can you abort" and the answers are essentially "you should not abort" - my question asks "Given that interrupt is better than abort, why isn't interrupt a supported feature? What mechanical hurdles prohibit this feature?". According to this question 的副本，中断 和 中止 线程之间存在重要区别，那个中断是更受欢迎的。
And, on matter of principle, it seems that there should be a way for the executor of the Task to be able to provide a guarantee of cancellation, rather than depending on the implementer of the Task to do things correctly with a cancellation token.
我不同意这种说法。任何困难都有很高的风险让您的系统处于不确定状态，它不能继续正常运行，尤其是当您试图中止您不拥有的代码的任务时。
如此设计的任务的优雅取消是避免这种情况的唯一方法。您是否希望生产中的系统（设计为 运行 24/7）泄漏资源并意外崩溃，或者只是在您无法取消 [=10] 时浪费一些额外的资源和时间=] 不包含 CacnellationToken?
这是我的个人意见，我发现 Task.Abort() 在大多数情况下有害无益。
编辑： 此外，Task 只是一个操作的句柄，您可以创建一个 TaskCompletionSource<T> 并在任何时候设置完成任何线程上的时间，因此无法追踪 Task 背后的逻辑代码实际为 运行ning 的线程。比如Task.WhenAll(Task[])returns一个Task。你会如何中止它？它不是 运行ning 在任何线程上，而是监听给定任务的完成。 IE。添加通用的 Abort 方法在技术上不可行。
线程支持中断。为什么没有任务？
从我（不知情的）角度来看，允许 Task 支持中断似乎是合理的：
- 如果任务当前未在线程上执行，则调用 task.Interrupt() 将设置一个 TaskInterruptException，以便在安排任务时抛出该异常。
- 否则，TaskInterrupException 将在执行任务的线程中抛出，该异常将在任务中捕获或添加到顶部的 AggregateException。我想这个功能需要任务知道正在执行的线程（这不合理吗？）
实现此功能所需的部分是否已经存在，或者这是否需要更改语言实现？
加法：
我已经阅读了许多关于讨论 killing/aborting 任务的问题，以及讨论 CancellationToken 和（气馁）Thread.Abort 方法的相关答案。
在我自己的摆弄中，我发现用CancellationToken.Register注册Thread.Interrupt并不会中断任务中的线程运行，而是中断在token上调用cancel的线程.
因此，在我看来，仍然需要允许开发人员确保可以（温和地）终止任务的认可功能。
我还要补充（以免有人说 "re-write your Tasks to take CancellationTokens"）在开发人员 不 拥有任务中正在执行的代码的情况下，此功能特别有价值.
而且，从原则上讲，似乎应该有一种方法让任务的执行者能够提供取消的保证，而不是依赖于任务的实施者来正确地做事取消令牌。
另加：
不管风险如何，C# API 支持 Thread.Abort 和 Thread.Interrupt。所以我的问题是，本质上，为什么 Task 不支持相同的 API（具有相同的固有风险）？
更新
此 post 已被标记为 this question. However, I had already read the referenced question before posting this one (and all of the answers) - this question is not a duplicate, but a related question seeking additional information. That question asks "can you abort" and the answers are essentially "you should not abort" - my question asks "Given that interrupt is better than abort, why isn't interrupt a supported feature? What mechanical hurdles prohibit this feature?". According to this question 的副本，中断 和 中止 线程之间存在重要区别，那个中断是更受欢迎的。
And, on matter of principle, it seems that there should be a way for the executor of the Task to be able to provide a guarantee of cancellation, rather than depending on the implementer of the Task to do things correctly with a cancellation token.
我不同意这种说法。任何困难都有很高的风险让您的系统处于不确定状态，它不能继续正常运行，尤其是当您试图中止您不拥有的代码的任务时。
如此设计的任务的优雅取消是避免这种情况的唯一方法。您是否希望生产中的系统（设计为 运行 24/7）泄漏资源并意外崩溃，或者只是在您无法取消 [=10] 时浪费一些额外的资源和时间=] 不包含 CacnellationToken?
这是我的个人意见，我发现 Task.Abort() 在大多数情况下有害无益。
编辑： 此外，Task 只是一个操作的句柄，您可以创建一个 TaskCompletionSource<T> 并在任何时候设置完成任何线程上的时间，因此无法追踪 Task 背后的逻辑代码实际为 运行ning 的线程。比如Task.WhenAll(Task[])returns一个Task。你会如何中止它？它不是 运行ning 在任何线程上，而是监听给定任务的完成。 IE。添加通用的 Abort 方法在技术上不可行。