why not flow control in wl_connection_flush?

[jleivent]

Thanks for this response.  I am considering adding unbounded buffering
to my Wayland middleware project, and wanted to consider the flow
control options first.  Walking through the reasonsing here is very
helpful.  I didn't know that there was a built-in expectation that
clients would do some of their own flow control.  I was also operating
under the assumption that blocking flushes from the compositor to
one client would not have an impact on other clients (was assuming an
appropriate threading model in compositors).

The client OOM issue, though: A malicious client can do all kinds of
things to try to get DoS, and moving towards OOM would accomplish that
as well on systems with sufficient speed disadvantages for thrashing.
A buggy client that isn't trying to do anything malicious, but is
trapped in a send loop, that would be a case where causing it to wait
might be better than allowing it to move towards OOM (and thrash).

On Thu, 22 Feb 2024 11:52:28 +0200
Pekka Paalanen <pekka.paalanen at haloniitty.fi> wrote:

> On Wed, 21 Feb 2024 11:08:02 -0500
> jleivent <jleivent at comcast.net> wrote:
> 
> > Not completely blocking makes sense for the compositor, but why not
> > block the client?  
> 
> Blocking in clients is indeed less of a problem, but:
> 
> - Clients do not usually have requests they *have to* send to the
>   compositor even if the compositor is not responding timely, unlike
>   input events that compositors have; a client can spam surfaces all
> it wants, but it is just throwing work away if it does it faster than
>   the screen can update. So there is some built-in expectation that
>   clients control their sending.
> 
> - I think the Wayland design wants to give full asynchronicity for
>   clients as well, never blocking them unless they explicitly choose
> to wait for an event. A client might have semi-real-time
>   responsibilities as well.
> 
> - A client's send buffer could be infinite. If a client chooses to
> send requests so fast it hits OOM, it is just DoS'ing itself.
> 
> > For the compositor, wouldn't a timeout in the sendmsg make sense?  
> 
> That would make both problems: slight blocking multiplied by number of
> (stalled) clients, and overflows. That could lead to jittery user
> experience while not eliminating the overflow problem.
> 
> 
> Thanks,
> pq
>