考虑到Async CTP通过环境SynchronizationContext
促进隐式调度,有没有理由不将我的CancellationToken
和IProgress
也变成环境变量呢?
目前我是通过方法传递它们,就像传递TaskScheduler
一样明确调度。然而,既然调度器现在应该是环境变量,那么这些拼图的其他部分是否也可以遵循同样的规则呢?
考虑到Async CTP通过环境SynchronizationContext
促进隐式调度,有没有理由不将我的CancellationToken
和IProgress
也变成环境变量呢?
目前我是通过方法传递它们,就像传递TaskScheduler
一样明确调度。然而,既然调度器现在应该是环境变量,那么这些拼图的其他部分是否也可以遵循同样的规则呢?
CancellationToken
比IProgress<T>
更有可能成为任务异步模式的候选对象。使用IProgress<T>
时,不同级别通常具有不同的T
(较高级别的异步方法会合并其低级别await
调用的进度通知)。而使用CancellationToken
,相同的令牌几乎总是传递到较低级别的异步方法中(假设它们支持取消)。CancellationToken
确实支持一些非常先进的组合器,但它们几乎从未使用。CancellationToken
- 所以您必须在最低级别的async
方法中显式获取它。此外,稍后维护您的代码库的程序员可能会期望TAP。CancellationToken
遵循async
方法的调用,即使它们更改线程上下文。我的意思是,请考虑以下内容:方法A
在等待方法B
的结果之前调用ConfigureAwait(false)
。您不能使用简单的线程局部静态属性,因为您需要从一个线程跟随异步执行上下文到另一个线程。CallContext
类?),但只要您这样做,性能立即降低(执行上下文迁移代码对于默认情况进行了高度优化)。