- 主题:boost/asio的协程调试非常麻烦，有没什么法子
报错了，指出了哪行报错，但是压根儿不知道是从哪个上次函数调用结束resume回来的，也就是不知道导致此报错的可能前面步骤是哪执行的（前面做了什么操作导致 线程恢复的时候 用到的资源不存在或者被释放了），调式相当痛苦，日志异步的，好像也没打印同步到出错的线程时执行了哪些操作？
有没经验分享一下？
--
FROM 14.154.42.*
协程这东东就是操作系统的 CPU 调度部分的代码。可以从操作系统内核那边抄不少理念和代码。
现在业界的走向有点意思，嫌弃:
1. TCP 实现太弱鸡了，我自己干—— QUIC
2. 网络协议栈实现太弱鸡了，我自己干—— DPDK
3. 文件系统实在太一般了，我自己干—— FUSE
4. 资源管理我自己干—— docker
5. CPU 调度我也自己来—— 协程。
【 在 ylh0315 的大作中提到: 】
: 没办法，这种事情全靠烧脑。
: 我自己写协程，不到1000行代码，调了4个月。晚上睡不着都在想问题在哪儿。自己写的，细节都非常清楚，还这样。
: 靠日志，追踪每个线程和协程的踪迹。日志要说明，哪个线程哪个协程。
: ...................
--
FROM 120.37.23.*
这1000行，有没有1万行的垃圾写法，写两个月，测两个月？
真心求教。
【 在 ylh0315 的大作中提到: 】
: 没办法，这种事情全靠烧脑。
: 我自己写协程，不到1000行代码，调了4个月。晚上睡不着都在想问题在哪儿。自己写的，细节都非常清楚，还这样。
: 靠日志，追踪每个线程和协程的踪迹。日志要说明，哪个线程哪个协程。
: ...................
--
修改:DoorWay FROM 113.137.166.*
FROM 113.137.166.*
不是弱鸡，是确实有点过时了，os、网络协议、语言特性都要照顾大量的旧设备和代码库，小厂根本无力改变，翻新速度全靠大厂用事实标准来推，去年研究quic的时候发现这玩意很nb啊，什么时候推广开了就好了，结果发现人家google早就铺开了，至少30%的流量已经是了
嵌入式这块仍然是重灾区，上一周在服务端各种新技术玩的飞起，这一周搞设备适配又回到armv7+gcc4.x，还好之前写的sdk只用到了c++11，如果是17就完蛋了
【 在 hgoldfish 的大作中提到: 】
: 协程这东东就是操作系统的 CPU 调度部分的代码。可以从操作系统内核那边抄不少理念和代码。
: 现在业界的走向有点意思，嫌弃:
: 1. TCP 实现太弱鸡了，我自己干—— QUIC
: ...................
--
FROM 219.142.253.*
这个线程池不用协程实现，会损失性能？
我的想法是，精巧的代码，得想4个月，不如用10000行平常的代码代替。
好调试。
【 在 ylh0315 的大作中提到: 】
: 两天就写完了，是在一个线程池的基础上打补丁，一共1000行，补丁也就二三百行。
: 最难的是那些不易复现的错误。
: 比如，一个协程需要因等待IO而挂起时，把自己的fd排进epoll，恰巧立即被激活了，被另一个线程抓住了，这边还没有swapcontext，那边就resume（setcontext）了。极少发生，必须长时间做压力测试才能发现。
: ...................
--
FROM 113.137.166.*
还真是
不过你说的这部分，都是特定场景的
内核更多的是考虑通用的
【 在 hgoldfish 的大作中提到: 】
: 协程这东东就是操作系统的 CPU 调度部分的代码。可以从操作系统内核那边抄不少理念和代码。
: 现在业界的走向有点意思，嫌弃:
: 1. TCP 实现太弱鸡了，我自己干—— QUIC
: ...................
--
FROM 106.11.31.*
总觉得这个活直接用现成的库就行了吧
c的轮子很少吗
【 在 ylh0315 的大作中提到: 】
: 之所以把线程池升级为协程是因为，这个服务器接收大量移动终端的低速网络数据传输。服务器8核，8线程。
: 一个终端传输数秒，期间如果超过8个终端同时传输，就占了8个线程。多余的就得等待。简单的方法就是多加线程，一行代码都不用写。实际上调试4个月时间就是这么干的。
: 那么，能否使传输过程，不要锁死一个线程呢？在等待IO时间能否让线程干其他事情呢？于是就动了这个心思。
: ...................
--
FROM 114.242.248.*
上万个请求python直接上就行了吧
【 在 ylh0315 的大作中提到: 】
: 可以呀。楼主不就用了吗？看看他遇到的问题。
--
FROM 114.242.248.*
牛逼
【 在 ylh0315 的大作中提到: 】
: 我主要是讲，为啥要用协程。就是异步过程的同步调用。
: 老系统是同步IO框架，其应用模块都是直接调用IO函数。
: 当修改成异步模式时，必须兼容原有的应用，确保其无需任何修改。
: ...................
--
FROM 114.249.22.*
那么复杂，报错就不意外了，建议简化逻辑。
【 在 ylh0315 的大作中提到: 】
: 现成的框架，异步失败就是失败。我的框架，异步失败就改同步，尽可能保证IO完成。
--
FROM 171.221.52.*