首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >为什么协同在调用线程上第一次运行,但是在第一个暂停点之后,它在“Dispatchers.Unconfined”中运行在Dispatchers.Unconfined上?

为什么协同在调用线程上第一次运行,但是在第一个暂停点之后,它在“Dispatchers.Unconfined”中运行在Dispatchers.Unconfined上?
EN

Stack Overflow用户
提问于 2019-02-14 16:48:24
回答 2查看 297关注 0票数 2

以下代码打印

代码语言:javascript
复制
import kotlinx.coroutines.*

    fun main() = runBlocking<Unit> {
        launch(Dispatchers.Unconfined) {
            // not confined -- will work with main thread
            println("thread ${Thread.currentThread().name}")
            delay(500)
            println("thread ${Thread.currentThread().name}")
        }
    }

第一次在调用线程上运行,但在第一个暂停点之后,它在“DefaultExecutor”中运行在“Dispatchers.Unconfined”中。

代码语言:javascript
复制
 thread main
 thread kotlinx.coroutines.DefaultExecutor
EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2019-02-14 17:12:48

阅读Dispatchers.Unconfined的描述,它会准确地解释这种行为:

不限于任何特定线程的协同线调度程序。它在当前调用帧中立即执行coroutine的初始延续,并允许coroutine在任何由相应的挂起函数使用的线程中恢复,而无需强制执行任何特定的线程策略。注意:使用时要非常小心,而不是一般代码

票数 2
EN

Stack Overflow用户

发布于 2019-02-15 11:20:29

Unconfined调度程序没有与其关联的线程。在几乎所有情况下,协同线都在用户调用continuation.resume()的线程上恢复。

在您所展示的特定情况下,您将调用标准函数delay,因此Kotlin必须在内部处理其暂停和恢复。为了实现这一点,它维护一个计划好的线程池,它向其中提交恢复任务,并按照您指定的延迟进行调度。

Unconfined调度程序仅在专用场景中有用,在这种情况下,您编写自己的基础设施,并希望控制协同线恢复的线程。基本上,它短路了整个调度员机制。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/54695301

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档