why not flow control in wl_connection_flush?
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?
Re: why not flow control in wl_connection_flush?
Hi, On Wed, Feb 21, 2024 at 4:21 PM jleivent 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
Re: why not flow control in wl_connection_flush?
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 wrote: > Hi, > > On Wed, Feb 21, 2024 at 4:21 PM jleivent 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
