why not flow control in wl_connection_flush?

[Pekka Paalanen]

On Sat, 24 Feb 2024 15:35:27 -0500
jleivent <jleivent at comcast.net> wrote:

> On Fri, 23 Feb 2024 12:12:38 +0200
> Pekka Paalanen <pekka.paalanen at haloniitty.fi> wrote:
> 
> 
> > I would think it to be quite difficult for a compositor to dedicate a
> > whole thread for each client.  
> 
> But that means it is possible that the server cannot catch up for long
> periods.  And that just having a large number of otherwise friendly
> clients can cause their socket buffers to fill up.  And things are
> worse on systems with more cores.

That can be true. Let me know when you hit that. It will be
interesting to hear what it takes to happen.

Even more interesting will be to hear if threading the client
connection handling will actually help, or is the compositor choking on
its own operations like repaint that need a snapshot of all clients'
state, because there are simply too many surfaces up.

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


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/20240226/07771871/attachment.sig>