xilem_masonry: Robust generational indexing for ViewSequence
#220
Conversation
| // The known solution mentioned in the above message is to use a different ViewId for the index and the generation | ||
| // We believe this to be superfluous for the default use case, as even with 1000 rebuilds a second, each adding | ||
| // to the same array, this would take 50 days of the application running continuously. | ||
| // See also https://github.com/bevyengine/bevy/pull/9907, where they warn in their equivalent case | ||
| // Note that we have a slightly different strategy to Bevy, where we use a global generation | ||
| // This theoretically allows some of the memory in `seq_state` to be reclaimed, at the cost of making overflow | ||
| // more likely here. Note that we don't actually reclaim this memory at the moment. | ||
|
|
||
| // We use 0 to wrap around. It would require extremely unfortunate timing to get an async event | ||
| // with the correct generation exactly u32::MAX generations late, so wrapping is the best option |
There was a problem hiding this comment.
Great writeup, and I agree, the probability that this happens per accident, is likely in the ballpark of a cryptographic hash collision... Not sure if this could be a security issue with a targeted attack, but I don't think we care at this point...
| } | ||
|
|
||
| fn count(&self) -> usize { | ||
| self.0.count() | ||
| } | ||
| } | ||
|
|
||
| const BASE_ID: NonZeroU64 = match NonZeroU64::new(1) { |
There was a problem hiding this comment.
For future reference, TIL about NonZeroU64::MIN
It's been a long time since I have had a `fmt` CI check fail
|
Merging to avoid merge conflicts over the weekend. I'm pretty happy with this now, and I think the main infrastructure work on (Also on the agenda is working out how to handle flex items - the idiomatic way is a specific |
Alternative to #218
The version of viewsequence added in #205 is robust for all properties supported in that version. However, it would be incompatible with future expansions to the Xilem model, in particular async wiring.
In this PR, I propose a system to resolve this, which uses generational indexes in the view id path (for the items where this is relevant).
Some other historical record: #9
This brings back the
View::Stateassociated type (renamed toViewStateandSeqStatedepending on the trait), in order to perform this wiring.