On Wed, 21 Feb 2024 11:08:02 -0500 jleivent <jleiv...@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 <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 >
pgp6eosZRij9S.pgp
Description: OpenPGP digital signature