On Tue, 27 Feb 2024 11:01:18 +0200 Pekka Paalanen <pekka.paala...@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?
