c++20的标准关于协程的跨线程调度是这么说的：
Resuming a coroutine via resume, operator(), or destroy on an execution agent other than the one on which it was suspended has implementation-defined behavior
unless each execution agent either is an instance of std::thread or std::jthread, or is the thread that executes main. [Note: A coroutine that is resumed on a
different execution agent should avoid relying on consistent thread identity
throughout, such as holding a mutex object across a suspend point. —end note] [Note: A concurrent resumption of the coroutine may result in a data race. —end note]
应该说已经比较清楚了
当然我也承认目前的实现从使用者角度来看绝对不够完美
不过标准这么定，应该还是从性能优先的角度出发，不想让规范过多地介入具体实现
另外协程本来就是一个不同的范式
和callback (hell) 、多线程一样可能需要对原来的代码甚至架构做较大修改
所以在引入之前要做好评估工作，防止之前的代码存在问题
个人观点哈
【 在 allegro (静水流深) 的大作中提到: 】
: 标 题: Re: 终于想明白协程了。
: 发信站: 水木社区 (Wed Sep 23 01:57:43 2020), 站内
:
:
: 【 在 MyWorkLife 的大作中提到: 】
: : 从c++20的角度来说不存在“协程恢复线程不确定”的问题
:
: 应该说是c++20没有规定“挂起和恢复协程的必须为同一个线程”这样可以实现一些线程池比如：
: cppcoro::static_thread_pool
:
: : 这种情况出现的原因是在suspend以后显式地跨线程转移了协程的handle
: : 这是技术设计上的选择，作为开发人员必然是非常清楚的
:
: 这个要求太高了，如果开发人员都非常清楚自己写啥，这个世界就没有了bug。
: production code中有很多这种函数，比如这种通过tls，把以前的不安全的code变成线程安全的。
:
: const char *map_str(const char *from)
: {
: thread_local to[1024];
: if(from){
: expensive_map_call(from, to);
: }
: return to;
: }
:
: 然后，如果协程上下文调用了这个map_str()函数，那么就implicitly的refer了这个tls。
: 而协程使用者和map_str()的作者可能根本不是同一个人，这会给协程使用者一个大surprise。
:
:
: : ...................
:
: --
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 158.140.1.*]
--
FROM 111.200.53.*