Lots and lots of places in the code had broken < operators because they are returning something like:
foo < other.foo or bar < other.bar;
but this breaks both the strict weak ordering requirements that are required for the "Compare" requirement for things like std::map/set/priority_queue.
For example:
a = {.foo=1, .bar=3}
b = {.foo=3, .bar=1}
does not have an ordering over a and b (both a < b and b < a are satisfied at the same time).
This needs to be instead something like:
foo < other.foo or (foo == other.foo and bar < other.bar)
but that's a bit clunkier, and it is easier to use std::tie for tuple's built-in < comparison which does the right thing:
(Initially I noticed this in SockAddr/sockaddr_in6, but upon further investigation this extends to the major of multi-field operator<'s.)
This fixes it by using std::tie (or something similar) everywhere we are doing multi-field inequalities.
The most significant implication of this looks to be that the OutboundMessage priority queue was not prioritizing correctly: messages would be prioritized by either msgID or priority, and so we could get fairly random prioritization rather than prioritizing by priority first, and then msgID only as a fallback among equal-priority messages.
Lots and lots of places in the code had broken < operators because they are returning something like:
but this breaks both the strict weak ordering requirements that are required for the "Compare" requirement for things like std::map/set/priority_queue.
For example:
does not have an ordering over a and b (both
a < bandb < aare satisfied at the same time).This needs to be instead something like:
but that's a bit clunkier, and it is easier to use std::tie for tuple's built-in < comparison which does the right thing:
(Initially I noticed this in SockAddr/sockaddr_in6, but upon further investigation this extends to the major of multi-field
operator<'s.)This fixes it by using std::tie (or something similar) everywhere we are doing multi-field inequalities.
The most significant implication of this looks to be that the OutboundMessage priority queue was not prioritizing correctly: messages would be prioritized by either msgID or priority, and so we could get fairly random prioritization rather than prioritizing by priority first, and then msgID only as a fallback among equal-priority messages.