关于webserver.cpp中的dealwithread()中两种反应堆是否阻塞的疑问

[B1uee]

看了将近半天，也查了issue，我发现大家普遍对reactor提出了问题，认为主线程需要一直while轮询确保读写操作完成，状态码改变，好像阻塞在这了。

除此之外，我对proactor也同样有疑问，if (users[sockfd].read_once())的意思应该是主线程自己读取了数据吧，假如是ET的话还需要循环读取完才能返回结果，那读取数据产生的这段“等待”时间，是否也算是“阻塞”呢？

还是说因为proactor是基于同步IO模拟的，因此读数据的过程是同步，不算阻塞，只有等待数据准备的过程才算阻塞呢？

[B1uee]

所以我的理解是，如果把“读”划分为两个阶段：

1. 数据准备阶段
2. 内核到用户空间的拷贝阶段

是否“阻塞”代表的仅仅是第一阶段的不同，在bool http_conn::read_once()中ET虽然会循环读取，但当数据未准备好时，会有errno == EAGAIN || errno == EWOULDBLOCK，因此也算非阻塞；而假设数据准备好了，花在等待if (users[sockfd].read_once())返回结果的时间，也只能算是同步

不知道这样的理解对不对，希望大佬指点一下

[common5]

reactor感觉是设计上有点问题，主线程死循环检测读写操作完成是为了在读写操作返回false的时候调用deal_timer释放资源，既然如此感觉不如直接把timer也放在users[sockfd]里一起传给工作线程，让工作线程去完成资源释放

[Lor1keet]

reactor感觉是设计上有点问题，主线程死循环检测读写作完成是为了在读写作返回false的时候调用deal_timer释放资源，既然如此感觉不如直接把timer也放在users[sockfd]里一起传给工作线程，让工作线程去完成资源释放

如果让工作线程处理的话，定时器链表不是线程安全的吧，会不会导致线程安全问题，如果加锁可能更复杂（不知道对不对