Tag the sqe's to fix the fsm handling a double send cqe
io_uring_prep_send can return multiple completions for partial data. However it can also return a 0 completion after a full completion which trips up the state machine as we move to expecting_reception after all the data is written.
The fix is to tag the user_data with the request type and ignore send done completions when in expecting_reception.
To see the bug use wrk which parses the responses and will hang when the bug occurs.
sudo apt install wrk
wrk -t1 -c32 -d2s http://localhost:8545/ -s json.lua
Also added a fix for never ending attempts to close already closed connections
if (is_corrupted())
if ( connection.stage != stage_t::waiting_to_close_k )
return close_gracefully();
Hi @MarkReedZ! Good catch!
Just a couple of clarification questions:
- Why are we using the top 4 bits? To store 4 states wee need only 2 bits. But it seems like you need 5 states (including zero), in that case you need only three state.
- How portable is pointer tagging on Linux?
One tiny request - can you please use clang-format for formatting? In VS Code I enable that extension by default on every save operation.
I'm looking for alternatives to the pointer tagging and I had a hack disabling auto formatting on save with VS code. I'll fix the formatting on my next commit.
The latest commit fixes another issue. I've added a new partial request test that does a full request followed by a partial. The code was passing { body.data(), input_size } to the parser instead of { body.data(), content_length }
Formatting update and moved the tagging to the lower 2 bits.
Hi @MarkReedZ! Thanks for your contributions, very useful!
I've added a few notes on things that catch my eye. Let me know if you can polish those!
PS1: I notice, that your git credentials may be ill-formed, as GitHub fails to link them to your account.
PS2: I traditionally squash your commits, renaming them to match the scheme recognized by the semantic versioning engine. If you name and structure the commit messages similar to the rest, it will be easier for me to preserve all of your work in the original shape.
Going forward I'll follow the commit message rules and squash my commits on the branch prior to the PR.