[PROPOSAL] thread_idx "lock" for communications #9
+29
−6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implemented the
thread_idx
"lock" I described on the call.An example of the client-side code to support this functionality is
E.g., if your
thread_idx
is wrong, it's because another message that you haven't seen yet was received by the server before your message. Thus, you may want to re-compute the message.To ignore this functionality - and never have a message bounced - you can just do the normal:
To motivate the utility of this function - imagine
PRP(A)
andPRP(B)
are mutually exclusive:AUS
sendsPRP(A)
andFRA
sendsPRP(B)
at ~ the same time, without knowing about the otherPRP
.AUS
sendsYES(B)
andFRA
sendsYES(A)
at ~ the same time, without knowing about the otherYES
.What happens then? The negotiation is in a weird state. If this happened to two people, they might realize the conflict and pause to clarify ... but the bots might not be sophisticated to handle this situation at this point.
A small test shows these kinds of race conditions are actually pretty common -- in a single round of communication, this code catches three race conditions: