On Fri May 17 08:36:29 2024 +0000, Jacek Caban wrote:
Thanks. It's better, but I still feel like client side implementation is not optimal. The nice thing about persistent mappings, like I mentioned earlier, is that we could just store and pass pointers, removing the need for both `get_thread_session_object_locator` and ref-counted session struct. We could for example just return an offset and shared object id in `set_thread_desktop` request and then store object pointer (from the offset) and id in `user_thread_info`. `get_cursor_pos` would then have all it needs to validate (with stored id), "lock" and use that pointer straight from the thread data.
To implement persistent mappings, we need to either give up growable memory, or map the newer extents in chunks.
I saw @rbernon's earlier comment that said "mapping the session in chunks is possible, but it's just a different approach and doesn't change much: instead of refcounting the session you'd need to add some logic to keep chunks around and map new ones."
For example, we'd need to keep the list of chunks. Also, the locator should now indicate which chunk the memory resides in (or somehow deduce it from offset).
Or maybe there's a simpler way that I missed?