On Mon Feb 19 11:09:34 2024 +0000, Alexandre Julliard wrote:
It does seem like overkill, and going in the wrong direction. I don't think we want to create a bunch of separate mappings for all kinds of objects. Ideally there would be just one mapping per desktop, with various structures allocated inside it.
Okay, I thought it could be useful for other objects at some point. At least for the purpose of the later changes, I intended to create mappings for thread inputs and for thread message queues.
I think having separate mappings for these makes the code much simpler as the mapping lifetime simply matches -or slightly exceed, until all references are released- the object lifetime. The clients can keep a reference on the mappings while they are using them and once they get stale -because thread input are detached, or because foreground input changes- call wineserver again to get the updated mapping.
I think managing these within the desktop mappings would simply make things much more complicated as we'd have to make sure they are not incorrectly reused, and synchronize with all clients possibly still reading from them.
Then I don't have any plan outside of these three object types, so we can probably have a more ad-hoc way instead of a new object ops, it was actually done that way initially. Would that be better?