On Mon Mar 10 11:02:04 2025 +0000, Rémi Bernon wrote:
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_t` 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 TID, object type and handle generation, and maybe what seems to be an offset at a different position but that's about it, no obvious client/server pointers, no PID either.
I think that one of more interesting optimizations is `IsWindow`, for which we need shared handle table and handle validation on top of that. Your approach will always need a server call for invalid handles.
You can name it differently, but you'll still have to have an object expected id (name it handle, `object_id_t` or anything) and its offset.
No, you don't need any expected id. As I said, unlike with NT handles, lifetime of the handle is the same lifetime of its underlying object. Handle validation is enough and it's something that would be good to have anyway (see above).
We'd indeed need an offset, but that's it.
The entry layout in your branch doesn't seem to match what I'm seeing on latest Windows 10, there's TID, object type and handle generation, and maybe what seems to be an offset at a different position but that's about it, no obvious client/server pointers, no PID either.
The offset is all you need. Whatever is missing in the handle table could be a part of the struct referenced by that offset.