On Fri, 1 Mar 2024 11:59:36 +0200 Pekka Paalanen <pekka.paala...@haloniitty.fi> wrote:
> ... > The real problem here is though, how do you architect your app or > toolkit so that it can stop and postpone what it is doing with Wayland > when you detect that the socket is not draining fast enough? You might > be calling into Wayland using libraries that do not support this. > > Returning to the main event loop is the natural place to check and > postpone, but this whole issue stems from the reality that apps do not > return to their main loop often enough or do not know how to wait with > sending even in the main loop. I am concluding from this discussion that I don't think clients would be constructed not to cause problems if they attempt to send too fast. I think I may add an option to wl_connection_flush in my copy of libwayland so that I can turn on client waiting on flush from an env var. It looks like it the change would be pretty small. Unless you think it would be worth making this a MR on its own? If the client is single threaded, this will cause the whole client to wait, which probably won't be a problem, considering the type of clients that might try to be that fast. If the client isn't single threaded, then it may cause a thread to wait that the client doesn't expect to wait, which could be a problem for that client, admittedly.