why not flow control in wl_connection_flush?

[jleivent]

On Tue, 27 Feb 2024 11:01:18 +0200
Pekka Paalanen <pekka.paalanen at haloniitty.fi> wrote:


> > 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 I was looking for!  I think... Maybe?

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

But, calling wl_display_flush too often is bad for throughput, right?
Isn't it better to allow the ring buffer to determine itself when to
flush based on being full, and batch send many msgs?  Obviously
sometimes the client has nothing more to send (for a while), so
wl_display_flush then makes sense.  But in this case, it does have more
to send and wants to know if it should attempt to do so or hold back.

I could instead wait for the display fd to be writable before
attempting each msg send.  But the display fd may be writable merely
because the ring buffer hasn't tried flushing yet.  But the ring buffer
could have less than enough space for the msg I'm about to send.  And
the socket buffer could have very little space - just enough for it to
say its writable.

Which means that sometimes polling the display fd will return writable
when an attempt to send a msg is still going to result in ring buffer
growth or client disconnect.

So... back to calling wl_display_flush ... sometimes.

I guess I could call wl_display_flush after what I think is about 4K
worth of msg content.  Wl_display_flush returns the amount sent, so
that helps keep the extra state I need to maintain.

Is there currently a way I could get the size of contents in the output
ring buffer?