记住 Async CTP 通过环境促进隐式调度SynchronizationContext
,有什么理由我不应该让我的CancellationToken
和IProgress
环境呢?
我目前正在通过方法传递这些,就像我正在传递一个TaskScheduler
明确的调度。但是,既然调度程序现在应该是环境的,我可能不会对拼图的其他部分遵循相同的规则吗?
记住 Async CTP 通过环境促进隐式调度SynchronizationContext
,有什么理由我不应该让我的CancellationToken
和IProgress
环境呢?
我目前正在通过方法传递这些,就像我正在传递一个TaskScheduler
明确的调度。但是,既然调度程序现在应该是环境的,我可能不会对拼图的其他部分遵循相同的规则吗?
CancellationToken
是比 更可能的候选人IProgress<T>
。使用IProgress<T>
,您通常T
在不同的级别上有不同的(更高级别的async
方法结合了其低级别await
调用的进度通知)。使用CancellationToken
,几乎总是将相同的标记传递给较低级别的async
方法(假设它们支持取消)。CancellationToken
确实支持一些非常高级的组合器,但它们几乎从未使用过。
主要缺点是您将背离基于任务的异步模式。您必须记住,任何 Microsoft 或第 3 方代码都需要显式CancellationToken
- sp 您必须在最低级别的async
方法中显式地将其从环境上下文中拉出。此外,稍后维护您的代码库的程序员可能会期待 TAP。
当您考虑实施时也存在挑战。您希望隐式CancellationToken
遵循async
方法的调用,即使它们更改了线程上下文。我的意思是,考虑一下:在等待方法结果之前A
调用方法。您不能使用简单的线程本地静态属性,因为您需要遵循从一个线程到另一个线程的异步执行上下文。ConfigureAwait(false)
B
我似乎记得读过有关执行此操作的方法(可能使用CallContext
该类?),但是一旦您这样做,您的性能就会下降(执行上下文迁移代码已针对默认场景进行了高度优化)。