On Sun Mar 9 11:10:04 2025 +0000, Jacek Caban wrote:
Yes, I was mostly thinking about how we approach the problem, not `gSharedInfo` itself. User handles are different than NT handles. They don't have a counterpart of `DuplicateHandle`, have the same value among processes, and objects' life time is tied to handle life time. That makes a shared handle table pretty straightforward. All we need is to be able to validate the handle and get a shm offset from it. That would eliminate the need for `get_shared_user_object` entirely and make using "locator" infrastructure an unnecessary complication. The layout of the table is a secondary concern, but with a shared handle table in place, making it compatible with modern 64-bit Windows version seems trivial.
The locator infrastructure is not something we can really get away from by using user handles.
You can name it differently, but you'll still have to have an object expected id (name it handle, object_id or anything) and its offset. Reading an object data will always require a similar read loop like we have for other objects, to ensure consistency of the data that's been read, checking the object id before and after, and retry locating the object if it was invalidated.
I don't really see the point, and I don't think it's a good idea to reimplement another similar data consistency mechanism just for user objects, that would use user handles instead of `object_id_t` like existing objects.
Yes, we can put the handle table in shm, put some of the information that seems to be there on Windows gSharedInfo, perhaps keep server and client pointers there[^1], but I think we should use obj_locator still to locate and identify objects in a stronger and more consistent way than user handles only would allow.
Our object ids are 64bit and increasing on any change, user handles are only 32bit and more subject to collisions or ABA races, and it doesn't seem better to use them for consistency.
To me, the unnecessary complication is to try to put another shared object model on top / aside the existing one when there no actual need for it. And making the handle layout table compatible looks far from trivial, or even useful, when it seem to regularly change.
[^1] The entry layout in your branch doesn't seem to match what I'm seeing on latest Windows 10, there's PID, object type and handle generation maybe what seems to be an offset at a different offset but that's about it, no obvious client/server pointers, no PID either.