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 <ofour...@redhat.com> wrote: > Hi, > > On Wed, Feb 21, 2024 at 4:21 PM jleivent <jleiv...@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
