Ben Laurie [mailto:ben@algroup.co.uk] wrote: > > I've asked Ben Laurie to review the patch for me. Once he > > says it looks OK > > I'll assign both the bug and the patch to Guido to deal > > with. Hopefully > > it's finally right. > > Doesn't seem quite right to me yet - the problem is that if > data arrives > 1 byte at a time with just less than the timeout between each > byte, then > you can get n*timeout as the actual timeout (where n is > potentially very > large). You need to reduce the timeout after each select, surely? Hmmm. The question is, how should the timeout be interpreted? The patch I submitted interprets it as the timeout for activity on the underlying socket itself, since that's the object on which you set the timeout by calling sock.settimeout(). You're suggesting that it should be interpreted as the timeout for the call to read() or write() on the ssl object, which involves potentially many separate socket operations. Anyone else have any opinion on the correct interpretation? I lean toward the one I've already implemented, since it requires no new work :-) > Apart from that, it looks good. Apologies for delay, I managed to > overlook this. No problem. - Geoff
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4