ssl: Fix windows IOCP socket path - #11510
Conversation
When events (renegotiate, alert, post_handshake_data) arrive during
an async send, they are postponed and low is set to 0 as a signal
to keep the sender in async_wait until the buffer fully drains.
In do_async_send/6, the {completion, _} branch called new_async/1
which overwrote low with the default (4096), losing the signal.
This caused unnecessary state ping-pong between async_wait and
connection on Windows (IOCP) when postponed events were pending.
Preserve low from the original async record and guard the
transition to connection on low > 0.
CT Test Results 2 files 66 suites 25m 18s ⏱️ Results for commit 4b20af8. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts
// Erlang/OTP Github Action Bot |
dgud
added
team:PS
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows (IOCP) edge case in tls_sender where postponed TLS events (renegotiate/alert/post-handshake data) could be mishandled during an in-flight async send due to the async buffer’s low watermark being reset to the default value.
Changes:
- Preserves
lowfrom the existing async buffer when rebuilding async state in the{completion, _}send path. - Guards the transition back to the
connectionstate onlow > 0to avoid ping-ponging when postponed events are pending.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@dgud I think it looks good maybe you could add a code comment, as for now I would not understand the code without the commit message for this PR. |
When events (renegotiate, alert, post_handshake_data) arrive during an async send, they are postponed and low is set to 0 as a signal to keep the sender in async_wait until the buffer fully drains.
In do_async_send/6, the {completion, _} branch called new_async/1 which overwrote low with the default (4096), losing the signal. This caused unnecessary state ping-pong between async_wait and connection on Windows (IOCP) when postponed events were pending.
Preserve low from the original async record and guard the transition to connection on low > 0.