如何解决SetSynchronizationContext的生存期是多长?
我有一个自定义SynchronizationContext,它抽象了一个自定义工作队列系统。我正在尝试编写一个帮助程序功能,以使客户端代码可以轻松为其编写代码。
我的助手功能当前如下:
void async Task QueueTaskWithCustomContext(Func<Task> task) {
var oldContext = SynchronizationContext.Current;
try {
SynchronizationContext.SetCurrent(new CustomSynchronizationContext());
// Yielding prevents any inline synchronous work from being done outside the work queue.
await Task.Yield();
await task();
} finally {
SynchronizationContext.SetCurrent(oldContext);
}
}
我希望像这样使用
await QueueTaskWithCustomContext(async() => {
await Something();
await SomethingElse();
});
我不知道这是不是犹太洁食,但它似乎适用于我抛出的测试用例。我对如何设置同步上下文以及它如何与异步代码交互感到有些紧张。特别是,在任何情况下,自定义同步上下文都可以“泄漏”到辅助功能之外并为其他任务设置吗?我在想是否不立即等待助手功能。经过一些快速实验后,我无法实现它,但是我仍然很紧张。
或者,即使在第一次等待之后,我设置try / finally块的方式是否也可以保证设置同步上下文?再说一次,我无法通过快速实验来实现它,但是我仍然对此感到紧张。
我想我不太了解设置SynchronizationContext的生命周期。是永久设置,还是直到取消设置,还是仅针对当前功能或...设置?
解决方法
特别是,在任何情况下,自定义同步上下文可能会“泄漏”到辅助功能之外,并为其他任务设置吗?
绝对:
QueueTaskWithCustomContext(async() => await Task.Delay(1000));
await Task.Delay(10);
较小的延迟将在您的自定义调度程序上运行,而不是默认调度程序上。
我全心全意地建议您不要使用这种退化的代码,您会给用户带来麻烦,除了任务调度程序会突然发生意外更改之外,还会使用户感到惊讶。
编辑:由于我没有明确回答您的主要问题,因此“当前”任务调度程序的生命周期就是线程的生命周期。它存储在TLS中,因此只要您的线程存在,它就会存在。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。