10:15 pq: KarenTheDorf, queueing a request is an operation that cannot fail (no API to fail), so when you try to queue a request, and the internal send buffer has no room left, and the flush into the socket also fails, libwayland-client runs out of options and marks the whole connection as failed. A recent fix was to enlarge the internal buffer.
10:17 KarenTheDorf: Yeah, I saw that recent change in the source. It also doesn't treat EAGAIN as fatal any more, at least in some places.
10:17 KarenTheDorf: But my local libwayland-client doesn't have that fix, so it's just a case of waiting for ubuntu to update.
10:18 pq: right
10:20 pq: It's like this, because we thought that asking clients to check the success of every single request queueing/sending function call would be too much to ask, and they might not even be able to postpone what they are doing in order to poll the socket for writable.
10:21 pq: In practise, it is very rare to hit the overflow though, because much of the Wayland interactions include waiting for the server to say something, so that gives time for the socket to drain.
10:22 KarenTheDorf: I've had it twice, I wish I knew what caused it. I'm *think* it's my touchpad bouncing a little and causing the pointer to enter/leave the surface lots and lots of times in a very brief period.
10:22 pq: hence it went unfixed for so long
10:23 pq: KarenTheDorf, did you say the disconnection is because the client is sending too much?
10:24 pq: Do you do "heavy" work in enter/leave event handlers, rather than just internally queueing a re-draw of the window?
10:24 KarenTheDorf: Grepping through the source for the error message I got points me to wl_closure_send failing, so I am assuming so.
10:25 KarenTheDorf: As I said, this has happened twice, and I'm just guessing at the cause. Because of course it doesn't happen when I have a debugger attached :D
10:25 pq: wl_closure_send is used by both sides
10:26 pq: a more common overflow is having a 1000 Hz mouse making the compositor flood the socket, I think
10:26 pq: while the client has a little stall
10:27 KarenTheDorf: So the output is "Error sending request: Resource temporarily unavailable" followed by an unhandled exception from my code because wl_display_get_error returned non-zero.
10:28 KarenTheDorf: Which I assumed was this line: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-client.c?ref_type=heads#L930
10:28 pq: "sending request" is client-side indeed
10:30 pq: maybe something caused the compositor to stall, or maybe the client could perhaps do something differently to avoid sending so much
10:31 KarenTheDorf: I could poll the wayland fd for writeability I suppose.
10:31 KarenTheDorf: But that only lets me avoid explicit flushes. If it's an implicit flush because the buffer filled that could be anywhere.
10:32 pq: that is a good idea, whenevere wl_display_flush() returns EAGAIN.
10:32 pq: yes, the implicit flushes are a problem
10:33 pq: maybe check what are you doing so much that you don't return to your main event loop to try explicit flushing and polling
10:34 pq: naturally is flush returns EAGAIN, one should avoid sending more requests until it succeeds again
10:34 pq: *if
12:15 pq: swick[m], if anyone posts MRs, feel free to land them in color-and-hdr by your judgment.
23:16 dd99: hello... first time here
23:22 vyivel: hi
23:31 wlb: weston Merge request !1518 opened by Leandro Ribeiro (leandrohrb) A few enhancements to the toytoolkit event loop https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1518 [Clients]