记一次顿悟的经历

2023.02.20 一次顿悟的经历

体验一次顿悟
​
需求：
​为避免接收数据时一直阻塞，先调用 select 在一定时间内判断是否有数据可读
如果超时，就报错没读到数据，即使返回
如果仍然在 set 里，就调用 recv 函数接收数据

问题：
服务端发送数据是 3 秒发一次，
设置客户端超时 sec 为 5 秒，结果很快就返回了。

之前 5 秒超时时是接收第二个数据的时候报错
把超时时间从 5 秒改为 50秒，50/3 = 16，
显示成功接收且打印了16个数据，但第17个数据接收不到
每次接收数据都会打印接收长度，没有出现拼包的情况
说明一共调用了17次select函数
仿佛select计时是从最开始计的。。。
16次 recv 函数
recv 是非阻塞调用

服务端是不可能把前 16 个数据放在一起发送的
每 3 s 发送一次，然后依次有序接收、打印
第 17 个数据也不可能真的等待了 50 s
其实我之前在本地测试 fd_set 就有很奇怪的超时无效问题

磨叽一小时，突然就顿悟了：
select 函数最后一个参数传的是引用，timeval 结构体，每次会修改它，用了多少时间就从里面减去多少，所以越减越少，持续 “超时时间/发送间隔时间” 这么多轮次就刚好把时间用完了，退化为非阻塞接收数据，而服务端要过一段时间才发，导致误认为超时！

我以为它不会变化，所以只初始化了一次，为了减少运算的悲剧。。。