Please sign in to comment.
Fix race condition in transaction handling
Once a server sends a response, it must be ready to receive a new message with the same tag. While using `defer` to clean up a tag once its message was handled was convenient, it ended up creating a race condition on low-latency connections with a highly parallel client (such as `v9fs`) like so: - Client sends Tmessage with tag X - Server sends Rmessage with tag X - Client sends Tmessage with tag X - Server refuses to handle Tmessage because X has not been cleared - Server clears X This change removes that race condition, re-arranging the order of operations to 1. Client sends Tmessage with tag X 2. Server handles message and clears X 3. Server sends Rmessage with tag X We've already cleared the tag for re-use before sending a response. An astute reader would note that with this re-ordering, a client may "steal" a tag before an Rmessage is received by using it between steps 1 and 2. However, the client would be violating the 9P protocol, as it has not received the corresponding R-message (because the server has not even sent it yet!), and only harms itself in this scenario, as it will become unable to recognise the tag on the Rmessage when it does come.
- Loading branch information...
Showing with 27 additions and 22 deletions.