On Mon Feb 19 11:24:12 2024 +0000, Rémi Bernon wrote:
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?
The issue is not so much the object ops, it's the separate mappings. I really don't think we want a mapping for every message queue and every thread input.