why not flow control in wl_connection_flush?

[Pekka Paalanen]

On Mon, 26 Feb 2024 13:23:01 -0500
jleivent <jleivent at comcast.net> wrote:

> 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.

That's what they definitely should do, if their other work ends up
blocking the thread. But if their other work is fast enough, then we
have no assumptions of using threads. Given lots of software is written
in C where threading creates more problems than it solves, allowing
apps to be single-threaded is a good idea to me.

> 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.

Many (most?) games and game framework libraries are prime examples of
difficult requirements. They can be "single"-threaded, which means we
should not block them, but at the same time their main loop may be a
busy loop of drawing new frames with very specific expectations on when
and where the window system should be blocking them to throttle their
framerate if the game so wants.

Sometimes users do not want throttling, but they will get it anyway,
because e.g. EGL and Vulkan have a limit on the number of framebuffers
per surface, so when you run out, the app gets blocked anyway waiting
for some buffer to be released from the compositor before drawing can
continue.

You can also write an app such that there is no limit on the number of
framebuffers, but then you risk OOM instead.

> 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?

Get the Wayland fd with wl_display_get_fd() and poll it for writable.
If it's not writable, you're sending too fast.

That's what any client should always do. Usually it would be prompted
by wl_display_flush() erroring out with EAGAIN as your cue to start
polling for writable. It's even documented.

I haven't followed the details of the libwayland message buffering MR,
but I would expect it to give you more grace time to poll, so you don't
have to go out of your way to check at inconvenient times.

And then there are the clients who don't care to poll for writable at
all.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240227/bec590d5/attachment.sig>