就是阻塞一个线程。协程并不绑定线程。IO很快就会完成，不过退化成线程池模式。就一个任务而言，使命必达不容夭折，其他任务可以等其他线程。而且同步只影响这一次IO。下次还可以恢复异步。
【 在 poocp 的大作中提到: 】
: 每个同步IO会阻塞一条线程的所有协程，所以全部线程/协程被阻塞的概率是存在的。
:
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

线程池有个数据结构来管理，里边有线程id。
tid=pthread_self();
得到当前线程的ID，在线程池里查询这个id，找到了，就利用这项数据进行yield。
找不到，就说明当前线程不是线程池里的线程，函数自动进入同步IO状态。
反正，IO是必须完成的，不管用什么方式。
【 在 DoorWay 的大作中提到: 】
: 检查当前线程id，和存储的线程数据？
: 线程数据里，包含了了协程帧的堆栈信息？
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

【 在 poocp 的大作中提到: 】
: 总之你这个模型被DoS的代价比较低，所以我建议你简化。
:
我的服务器方案，由主线程创建线程池，context等等，线程池由epoll调度。
主线程守护监听socket。由select监听。收到事件取一个context，然后用这个context 进行accept，并记录时间戳，，把这个context投入epoll，交给线程池处理。
在DDOS攻击期间，context可能被迅速耗尽，这时主线程取不出来context，就进入一个循环，不断进行timeout检测，检测发生timeout的contex，收拾出来垃圾再继续处理。
被accept的socket，必须在一定时间内对口令，超时被踢。
已经完成认证的socket就在epoll的事件循环中完成它们的任务，不受ddos攻击的影响。期间accept是有卡顿的，不过几秒钟后就会有大批的无效socket被踢，accept可以迅速恢复。
不知道你们的单线程协程是怎么抵抗DDOS攻击的。
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

还一个办法，做通用工具，好容易调好一个，以后到处用。
【 在 Algoquant 的大作中提到: 】
: 报错了，指出了哪行报错，但是压根儿不知道是从哪个上次函数调用结束resume回来的，也就是不知道导致此报错的可能前面步骤是哪执行的（前面做了什么操作导致 线程恢复的时候 用到的资源不存在或者被释放了），调式相当痛苦，日志异步的，好像也没打印同步到出错的线程时执行了哪些操作？
: 有没经验分享一下？
--
FROM 221.218.60.*

if (epoll_ctl(epollFd, EPOLL_CTL_ADD, listenFd, &event)) {
             throw std::runtime_error("Failed to add listenFd to epoll");
         }
这句话删除，在运行函数里已经有了select守候。
【 在 Algoquant 的大作中提到: 】
: 以下由ds生成：
: #include <iostream>
: #include <thread>
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*