- 主题:觉得协程不是一个太好的编程模型
感谢。
多保留一个信号量掩码，也行。
每个协程有自己的，可能遇到了什么问题而做。
其他就是一个get一个set。它不調函数了，直接干，稍稍快一点。
总的来说，这套协程工具挺好的。
【 在 hgoldfish 的大作中提到: 】
: linux 的实现比较奇葩一些。有个 signal 的处理进了内核。
: github dotcom/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/x86_64/swapcontext.S#L74
:
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
那为什么 linux 不改？
【 在 hgoldfish 的大作中提到: 】
: 原理是这样没错。但 linux 实现的 swapcontext() 比较奇葩，会陷入内核。所以这几个 posix 函数没人用。
--
FROM 36.101.222.*
兼容性问题吧。POSIX 里面是这样的规定的。
基本上大家就是默默地把 swapcontext 的那部分源码拿过来，然后去掉 signal 的处理，就搞出自己的纤程实现了。
话说，我也没看懂那段 signal 处理是干嘛用的。反正 boost 也没处理 signal，避免陷入内核。不陷入内核的话，纤程的切换和函数调用没差多少。
【 在 chaobill 的大作中提到: 】
: 那为什么 linux 不改？
--
FROM 117.28.161.*
陷入内核也没啥，就是改个标志，没有IO也没有事件。
每个协程有自己的掩码而已，估计是调度器的需求。
我能想象的是，用signal中断当前协程进入调度程序，也允许协程屏蔽这个信号。
【 在 hgoldfish 的大作中提到: 】
: 兼容性问题吧。POSIX 里面是这样的规定的。
: 基本上大家就是默默地把 swapcontext 的那部分源码拿过来，然后去掉 signal 的处理，就搞出自己的纤程实现了。
: 话说，我也没看懂那段 signal 处理是干嘛用的。反正 boost 也没处理 signal，避免陷入内核。不陷入内核的话，纤程的切换和函数调用没差多少。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
多谢，看明白了。
IOCP可以用作线程池调度。
也可以做多线程协程。
【 在 z16166 的大作中提到: 】
: 排队和派发是windows内核实现的，并不开源，哈哈
: 让chatgpt帮你写个简单的IOCP例子就知道了
: 或者MS的这个例子
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
协程如果只用作文件 IO 调度就太可惜了。
举个例子，opencl 提交多个任务，异步等待 gpu 计算完毕返回，也很适合协程模型。
总之，看到异步，就可以想到协程。
除了异步，协程还很适合拿来搞迭代器，在实现词法解析的时候是神器啊。
【 在 ylh1969 的大作中提到: 】
: 多谢，看明白了。
: IOCP可以用作线程池调度。
: 也可以做多线程协程。
: ...................
--
FROM 110.84.120.*
我主要是socket异步IO。
GPU是个有意思的用途，考虑过，可惜没机会玩了。
词法解析，一直在浅度运用，没想出来怎么用协程，不过这个题目有意思。
【 在 hgoldfish 的大作中提到: 】
: 协程如果只用作文件 IO 调度就太可惜了。
: 举个例子，opencl 提交多个任务，异步等待 gpu 计算完毕返回，也很适合协程模型。
: 总之，看到异步，就可以想到协程。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*