c# - 使用 CancellationTokens 作为事件的替代品有哪些优点和缺点？

Question

最近我遇到了a Microsoft interface使用一个非常不寻常的 API:

public interface IHostApplicationLifetime
{
    public CancellationToken ApplicationStarted { get; }
    public CancellationToken ApplicationStopping { get; }
    public CancellationToken ApplicationStopped { get; }
}

属性(property)的文件ApplicationStopping令人困惑地暗示此属性实际上是一个事件(强调已添加):

Triggered when the application host is performing a graceful shutdown. Shutdown will block until this event completes.

看来应该是什么繁体EventHandler事件，已​​替换为 CancellationToken属性(property)。这就是我的预期 界面为:

public interface IHostApplicationLifetime
{
    public event EventHandler ApplicationStarted;
    public event EventHandler ApplicationStopping;
    public event EventHandler ApplicationStopped;
}

我的问题是，这两种通知机制是否等效？如果不是，从 API 设计者的角度来看，每种方法的优缺点是什么？ CancellationToken 属性在哪些情况下优于经典事件？

Answer 1

Microsoft 应该更小心地处理文档。将 CancellationTokens 描述为要“触发”的事件是令人困惑的。

我当然不是 C# 语言专家，所以希望社区让我们知道我是否遗漏了重要的要点。但是让我来谈谈一些事情......

那么您的问题:它们是否等同.. 仅在它们都提供注册和调用回调的方式的意义上。但出于很多其他原因，不。

CancellationToken s 是 CancellationTokenSource 的包装器.它们与任务实现相关联。它们是线程安全的。它们可以被外部调用，也可以被定时器调用。您可以将多个 CancellationTokenSource 链接在一起。它们维护指示它们是否已取消的状态，您可以查询该状态。

C# events ，语言功能，在文档中是一个特殊的多播委托(delegate)。它们只能在声明它们的类中调用。 They are not really thread safe .它们被烘焙到 XAML 和 WPF 中。

我不会过多地评论一个比另一个优越的地方，因为它们非常不同。在正常情况下，我认为您不会在考虑 CancellationTokens 的情况下考虑事件。它们在 IHostApplicationLifetime 的情况下重叠，主要是因为糟糕的文档和 .NET Core 的托管基础​​设施的重新设计。正如@EricLippert 提到的 link提供了一个很好的概述。