Smithay assumes monotonically increasing serials

[smithay]

Smithay assumes monotonically increasing serials

[elinorbgr]

Indeed, serials should "only" be locally monotonically increasing.

Probably we should add a Serial abstraction that takes the wrapping around into account correctly.

the default serial counter which is said to wrap around on overflow

I'd also add that next_serial() returns a u32 even when usize has 64 bits, so the wrap-around (generated serial is smaller than the previous one) may happen even before that.

Is it reasonable to assume that at most u32::MAX serials have been generated between the ones being compared? If so, it could be solved storing a bool that toggles when the wrap-around happens. Then, if two serials are compared and that flag is different, we can just invert the comparison (e.g. s1 <= s2 instead of s1 > s2.) Because at most u32::MAX serials were generated, the inverted condition should hold.

[elinorbgr]

I had in mind making an implementation of a serial counting taking wrap-around into account based on the fact that serials are overall quite short-lived. So even though a long-lived compositor may wrap-around the u32 in the serials it generates, the actual set of "live" serials should be much closer to each other than that.

So my idea was that if the distance between the two serials is greater than u32::MAX / 2, then assume that a wrap-around occurred between the two.

So, making a Serial(u32) type, with a custom PartialOrd impl taking that into account.

Fair enough. I've made a pull request to do that: #230

It's my first time using git to contribute to someone else's project, so please let me know if I screwed up.

[elinorbgr]

Fixed in #230