On Mon, 26 Feb 2024 15:12:23 +0200 Pekka Paalanen <pekka.paala...@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?
