redisGetReply timeout issue

[HelloAWorld]

在windows平台，
1.使用了redisConnectWithTimeout进行连接，设置了超时间，
2.使用subscribe命令是该连接进入了subscribe模式，
3.使用redisGetReply获取订阅结果，
4.问题：a.发现调用redisGetReply立即返回的-1, redisreply为空, redisContext错误被设置成了unknow error, 连接又是正常的，
b.通过publish发消息，也显示有包括该连接收到了订阅结果,继续调用redisGetReply仍旧返回-1， 错误一直是unknow error
5.问题排查，
跟踪redisConnectWithTimeout函数，发现在连接时将套接字设置了非阻塞，连接成功后要将套接字设置为阻塞模式，也即套接字还是阻塞模式，会对send/recv设置超时时间
跟跳redisGetReply发现，a.在中途会判断redisContext->err不为0，则直接返回不继续向下
b.继续跟踪redisGetReply调用，发现第一次调用时，在底层net.cpp 里函数redisNetRead调用recv失败返回-1后，取errno ，发现错误码可能为WSAETIMEDOUT （10060）或者ETIMEDOUT(138)错误， 而redisNetRead里只有判断为非阻塞返回EWOULDBLOCK或者返回EINTR时是正常的情况， 没有对可能为WSAETIMEDOUT （10060）或者ETIMEDOUT(138)错误的判断为正常，附图国啊判断逻辑后发现可以正常接收到数据了

[michael-grunder]

Hi, @HelloAWorld

I'm not completely sure if I understand your question, but you mention trying to use redisConnectWithTimeout on Windows, so I have a guess as to what your issue is.

We have an open PR to fix an incompatibility between Windows and Linux:
#662

I haven't looked closely at the PRs but essentially in Windows, a 1-second timeout is being treated as 1ms.

Try building code based on the PR and see if your problem goes away.

[HelloAWorld]

Hi, @michael-grunder
Thank's for your reply. This is the first time I Submit issue. Maybe I submitted it in Chinese Puzzled you。
My Questom Is, When I Called redisConnectWithTimeout Connected redis, and Use subscribe Command subscrie some channels, then Called redisGetReply , It fastly returned with reply is NULL, and the redisContext is set to Unknow error. This I don't mean It fastlty returned ignore timeout is setted, But It just returned error whether the connection is Established. Trace call chain , I find redisNetRead function a bug, when recv call returned -1 and the errno is WSAETIMEDOUT(10060) or ETIMEDOUT(138), It may be normal case, but now it's judged as Unknow err that what a meet. The picture for redisNetRead function I pointed is I try to fix the problem and it's looks ok.

[michael-grunder]

I think this was fixed in #670 but feel free to reopen if I'm mistaken.