why not flow control in wl_connection_flush?

[Pekka Paalanen]

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

> On Wed, 21 Feb 2024 16:39:08 +0100
> Olivier Fourdan <ofourdan at redhat.com> wrote:
> 
> > Hi,
> > 
> > On Wed, Feb 21, 2024 at 4:21 PM jleivent <jleivent at comcast.net> wrote:
> >   
> > > I've been looking into some of the issues about allowing the
> > > socket's kernel buffer to run out of space, and was wondering why
> > > not simply remove MSG_DONTWAIT from the sendmsg call in
> > > wl_connection_flush?  That should implement flow control by having
> > > the sender thread wait until the receiver has emptied the socket's
> > > buffer sufficiently.
> > >
> > > It seems to me that using an unbounded buffer could cause memory
> > > resource problems on whichever end was using that buffer.
> > >
> > > Was removing MSG_DONTWAIT from the sendmsg call considered and
> > > abandoned for some reason?
> > >    
> > 
> > See this thread [1] from 2012, it might give some hint on why
> > MSG_DONTWAIT was added with commit  b26774da [2].
> > 
> > HTH
> > Olivier
> > 
> > [1]
> > https://lists.freedesktop.org/archives/wayland-devel/2012-February/002394.html
> > [2] https://gitlab.freedesktop.org/wayland/wayland/-/commit/b26774da  
> 

-------------- 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/20240222/2f0357f2/attachment.sig>