GitLab
gitlab-to-mail https://gitlab.winehq.org/project_5_bot1 started a new discussion https://gitlab.winehq.org/wine/wine/-/merge_requests/1111#note_12406:
Zebediah Figura replied on the mailing list:
|> >> >> Should we add tests for the TIME_WAIT part as well? >> > I don't know how to do that 100% reliably for a non-flaky test, the way
I use locally is creating child processes which connect to each
other > and killing them. But that results in different TCP connection states on > ports and sometimes (rarely) they may get lucky and not hit the longest > timeout. Should I maybe attach a local program which reproduces that? Is it not sufficient to close sockets in-process?|
I think it is not always sufficient (especially if those are not localhost process) and also not possible. In the ultimate case if the process is force killed on host (kill -KILL) we don't have any sane way to close the sockets, and we want this case to work too. In the less ultimate case when the process is closed through winapi attempting that is still problematic. I am not sure it is valid to call 'closesocket' on behalf of the app (thus interfering with its communication with the peer). Then, it is not guaranteed that peer will answer in time and the socket gets fully closed without waits.
|I think in general there's value in tests that don't always fail without a fix, provided that they always succeed with it—i.e. they still can help prevent regressions—but in this case maybe it's not worth it if the test gets too ugly (or if the relevant case is too rarely hit).|
Well, it seems to me that the way it is done more or less reliably (like in my attached program) is ugly enough and I'd suggest not to add it. Please let me know if you think it still worth it.