Follow-up from "fix handling of TCP timeouts"
The following discussion from !7937 (merged) should be addressed:
-
@aram started a discussion: (+2 comments) While you are addressing Ondřej's comments, would you please also look at something not strictly related to this MR, which caught my eye (cc @ondrej):
void dns_dispatch_resume(dns_dispentry_t *resp, uint16_t timeout); /*%< * Reset the read timeout in the socket associated with 'resp' and * continue reading. * * Requires: *\li 'resp' is valid. */
The function is supposed to reset the read timeout, but if I am reading the code correctly, both
udp_dispatch_getnext()
andtcp_dispatch_getnext()
(called bydns_dispatch_resume()
) potentially can ignore the timeout value if the read operation is already ongoing. Is that by design?I think it should at least update the
resp->timeout
value with the new one, and probably callisc_nmhandle_settimeout()
even when already reading, in case if the new timeout is smaller than the remaining time of the current one.