why not flow control in wl_connection_flush?

[jleivent]

Not completely blocking makes sense for the compositor, but why not
block the client?

For the compositor, wouldn't a timeout in the sendmsg make sense?

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