why not flow control in wl_connection_flush?

[jleivent]

On Fri, 1 Mar 2024 11:59:36 +0200
Pekka Paalanen <pekka.paalanen at 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.