why not flow control in wl_connection_flush?

[jleivent]

On Mon, 26 Feb 2024 15:12:23 +0200
Pekka Paalanen <pekka.paalanen at haloniitty.fi> wrote:

...
> > What is the advantage to having the impacted clients grow their send
> > buffers while waiting?  They wait either way.  
> 
> They are not waiting if they are growing their send buffers.

I meant that they must wait for the UI to update corresponding to the
messages they are trying to send to the compositor.

This may as also be about my assumption of a threading model, this time
for the client.  I assume that a client that has some important work to
do that is unrelated to updating the display will do that work in a
distinct thread from the one dedicated to sending display related msgs
to the compositor.

If that's not the case, then indeed causing the client's sending thread
to wait could impact some other computation.  Which might be bad,
depending on what that other computation is trying to do.

But suppose I'm writing a client that has the possibility of sending a
rapid stream of msgs to the compositor that might be, depending on what
other clients are doing, too fast for the compositor to handle, and I'd
like to implement some flow control.  I don't want the connection to
the compositor to sever or for the condition to cause memory
consumption without any ability for me to find out about and control
the situation.  Especially if I could slow down that rapid stream of
updates without too high a cost to what my client is trying to
accomplish.

Is there a way I could do that?