- 主题:boost/asio的协程调试非常麻烦，有没什么法子
是没几句话，但你在上万并发的纤程里用同步IO，你自己品。
【 在 ylh0315 的大作中提到: 】
: 逻辑很简单，异步失败，设置成同步继续IO，没几句话。
--
FROM 171.221.52.*
每个同步IO会阻塞一条线程的所有协程，所以全部线程/协程被阻塞的概率是存在的。
【 在 ylh0315 的大作中提到: 】
: 没问题。系统可以承担少量同步过程。
: 失败毕竟是极少数。
--
FROM 171.221.52.*
总之你这个模型被DoS的代价比较低，所以我建议你简化。
【 在 ylh0315 的大作中提到: 】
: 是的，但是，我的是多线程协程。线程协程之间没有绑定关系。最多就是退化成线程池模式。就是系统没有改造升级的状态呗。
--
FROM 171.221.52.*
更好的方案是将异步IO失败的链接从处理中移除，放在单独的线程/协程里排队做同步IO重试，这样它们只会阻塞自己，不会影响主要工作线程。
【 在 ylh0315 的大作中提到: 】
: 这个早有考虑。
: 协程有限，呼叫成功一个分配一个。
: DDOS一般是无协议呼叫，不符合既有的协议，在对协议的过程中就被踢了。不会为它分配协程。已有的协程继续工作，基本不受影响。
: ...................
--
FROM 171.221.52.*
检查当前线程id，和存储的线程数据？
线程数据里，包含了了协程帧的堆栈信息？
【 在 ylh0315 的大作中提到: 】
: 我的方法是透明的，用户并不知道什么同步异步，只是调用一个Net_Recv函数，一切问题都必须在这个函数里解决。成功了数据就有了，失败就是失败，我只能尽可能的不让它失败。这些多余的动作，我做不了，用户也做不了。用户也不知道进程线程协程啥的。
: 这个函数也可以在多进程多线程多协程等各种模式下工作。
: 函数入口就判断模式，是协程就按异步工作，否则就是同步工作。异步失败就转同步，要尽可能的完成任务，使命必达。黑猫白猫，完成任务就是好猫。
: ...................
--
FROM 61.185.161.*
弱问是业务需要读完再做其他耗时的操作才选择多线程的吗？
没用过boost.asio,猜测他应该是能单线程应对大量连接的吧（非协程）
【 在 ylh0315 的大作中提到: 】
: 之所以把线程池升级为协程是因为，这个服务器接收大量移动终端的低速网络数据传输。服务器8核，8线程。
: 一个终端传输数秒，期间如果超过8个终端同时传输，就占了8个线程。多余的就得等待。简单的方法就是多加线程，一行代码都不用写。实际上调试4个月时间就是这么干的。
: 那么，能否使传输过程，不要
: ..................
发自「今日水木 on SunOS 5.6」
--
FROM 140.207.23.*
20年前就用这个 State Thread，已经15年没更新了，其实和协程很相似
【 在 ylh0315 的大作中提到: 】
: 之所以把线程池升级为协程是因为，这个服务器接收大量移动终端的低速网络数据传输。服务器8核，8线程。
: 一个终端传输数秒，期间如果超过8个终端同时传输，就占了8个线程。多余的就得等待。简单的方法就是多加线程，一行代码都不用写。实际上调试4个月时间就是这么干的。
: 那么，能否使传输过程，不要锁死一个线程呢？在等待IO时间能否让线程干其他事情呢？于是就动了这个心思。
: ...................
--
FROM 221.216.147.*
就是阻塞一个线程。协程并不绑定线程。IO很快就会完成，不过退化成线程池模式。就一个任务而言，使命必达不容夭折，其他任务可以等其他线程。而且同步只影响这一次IO。下次还可以恢复异步。
【 在 poocp 的大作中提到: 】
: 每个同步IO会阻塞一条线程的所有协程，所以全部线程/协程被阻塞的概率是存在的。
:
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
你这种太麻烦。
【 在 poocp 的大作中提到: 】
: 更好的方案是将异步IO失败的链接从处理中移除，放在单独的线程/协程里排队做同步IO重试，这样它们只会阻塞自己，不会影响主要工作线程。
:
--
FROM 221.218.60.*