On Fri May 17 08:36:29 2024 +0000, Jacek Caban wrote:
With separate mappings out of the way, it's much closer now to what we will need for user handles. There are some unneeded differences, through. The assumption that shared mapping is an array of fixed size objects is something that would need to be changed to objects like windows. While things like an allocator may be changed later, I'd suggest to keep the layout private to server at this point by replacing object index with a mapping offset.
I don't think we can make object layout private to the server without changing, again, the object synchronization logic, and it is not trivial.
We use object ids to decide on whether objects have been invalidated, from the client side, and whether server needs to be called. The ids are located in the object headers and are never used for something else, and therefore are safe to use from the client side as an object invalidation marker.
Changing object layouts to be fully variable in size would require knowledge from the server side, of whether objects are still referenced from the client side or not, before they can be actually reused. This introduce an additional synchronization requirement that would IMO be better to avoid.
If we need variable sized window data, we can always put it after the object array, in a completely variable size shared heap and the window objects would have an offset to their variable data. The object synchronization stays the same, and the variable data and offset are valid only while the object itself is valid and may be read only while the object is locked.
Then TBH I don't like much the idea of implementing a shared heap on the server side, it introduces a lot of complexity and potential source of failures, and I avoided it here for that reason.