Jacek Caban (@jacek) commented about dlls/win32u/window.c:
if (!get_user_entry( handle, type, &entry, &handle )) object = NULL;else object = find_shared_session_object( entry.id, entry.offset );if (!object) status = STATUS_INVALID_HANDLE;- }
- if (!status && (!lock->id || !shared_object_release_seqlock( object, lock->seq )))
- {
shared_object_acquire_seqlock( object, &lock->seq );if (!(lock->id = object->id)) lock->id = -1;*object_shm = &object->shm;return STATUS_PENDING;- }
- if (!valid) memset( lock, 0, sizeof(*lock) ); /* object has been invalidated, clear the lock and start over */
What’s the idea behind this, do you expect the window object ID to mutate?
If not, we could simplify the code by grabbing the id on the first lock. In fact, we might not need the id at all, we could use the window handle for validation and the handle entry for the offset.
(Later on, we might even consider storing a shared pointer in the `WND` struct. Several of its fields can only be modified by the current process while holding the user lock, so once we have a `WND` pointer, we should be able to read those fields directly from shared memory without additional locking, instead of duplicating them on client side. It’s not a deal breaker if that doesn’t work out, but I’d be curious to know why not.)