20:06 <riteo> Hi, I'm in the process of refining my current project (see logs for more info) with a protocol proxy that changes messages on the fly to multiplex two clients into one

20:06 <riteo> it's basically a weird embedding compositor

20:07 <riteo> enough context given, here comes the actual question

20:09 <riteo> I'm currently passing through blindly all messages for registry global instances (the objects bound with `wl_registry::bind`), but this is an issue as when a client is closed, there are some "orphaned" objects, basically becoming a small leak. I'm wondering, is there any protocol behavior that depends on every each bound instance, or are all events/requests pointing to a virtual global object in the compositor logic?

20:10 <riteo> I'm planning to do a similar thing, redirecting all global registry objects requests/event from/to a single proxy-wide instance, but I wonder if I'm going to be bitten by it in the future.

20:36 <riteo> sorry if the question is hard to understand, I had trouble putting it into words.

20:42 <Consolatis> if the proxy outlives the client(s) I think you need to track objects created by the clients (including objects created by other objects) to ensure those are cleaned up correctly when the client disconnects. I assume there are a lot of clients out there that don't clean up after themselves but just disconnect and rely on the compositor doing the cleanup.

20:43 <Consolatis> depending on your use-case you might be able to proxy every client on its own dedicated "upstream" wayland connection and when the client terminates just disconnect that client connection to upstream

20:57 <riteo> Consolatis: I'm already tracking objects and cleaning them up... when possible at least, and that's kinda the problem

20:57 <riteo> also I can't do the per-client connection thing

21:00 <riteo> to put in in other words, let's say that every time a client binds a new wl_shm (version 1) and then that client quits

21:00 <riteo> since it's version 1 I can't clean it so it kinda sits there in my proxy's memory

21:01 <riteo> now, what if I stored a single "instance" in the proxy memory and when the client binds to that global I just... fake it? That's the question really, is there any special behavior that distinguishes between multiple wl_registry globals?

21:02 <riteo> *between multiple wl_registry global instances (wl_registry::bind)

21:24 <vyivel> riteo: i'd open a new connection per client

21:24 <vyivel> ...oh wait you said you can't do that

21:26 <riteo> yea I don't want to re-explain everything each time but this is basically an homebrew version of XEmbed for a preview feature in Godot I'm porting to Wayland

21:26 <vyivel> no i remember that

21:27 <riteo> oh aight

21:27 <vyivel> off the top of my head i think mirroring globals should be fine

21:27 <riteo> that's good to hear!

21:27 <vyivel> except maybe for stuff like xdg_wm_base pinging but that probably is fine too

21:28 <riteo> at this point I think trying it is worth it, outside of globals there's basically zero leakage

21:28 <riteo> like it's not even an ID thing (we've got 32 bits lol) but more of a slow memory thing as users are going to restart the embedded game a lot in a single session

21:28 <riteo> I mean it's probably a few bytes each time but it's still something

21:29 <vyivel> meanwhile mesa wsi recreating wl_registry on every resize

21:29 <riteo> WAT

21:29 <riteo> that's... concerning

21:30 <vyivel> i have no idea why is it done but wl_fixes at least provides a way to clean up those registries

21:31 <riteo> yea... wl-fixes... The thing I explicitly did not enable in the proxy as I'm assuming a static wl-registry

21:32 <riteo> uh actually it should not be hard to emulate exactly because of that

21:32 <riteo> still

21:32 <riteo> yea, going to try mirroring registry globals soon, ty for chipping in!

21:32 <vyivel> good luck with that