Explictly avoid double-resumption of tasks during Libevent2TCPConnection.close(). Fixes #1441. #1443
Conversation
…ion.close(). The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.
|
I looked at the code. Seems good. One thing though, the error I had in #1441 was because SSL_shutdown was sending a close notification on a socket that got terminated at the other end, which tripped the internal logic and caused the freeze. Shouldn't the client in the test case send something (to simulate the SSL_shutdown) before the call to In any case, tomorrow I will run my program with this branch and see what happens. |
The case also fails as expected on master. |
|
Isn't that the server? I was talking about inserting |
|
I can confirm this fixes my issue |
|
Ah okay, but it shouldn't matter whether it is the server or the client that tries to do the send. The connection is basically symmetric in all aspects that matter, after the initial handshake. The dub registry is also running flawlessly so far (still too early to judge, but it usually stalled after a few hours max. recently). |
Explictly avoid double-resumption of tasks during Libevent2TCPConnection.close(). Fixes #1441.
|
Ah, good old symmetry. |
The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.
See #1441.