3 ms·

Wayland Proxy Load Balancer

Vilian 3y ago
its the same "problem" that was fixed on QT? https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/ https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustnes... or it's other issue?
- ptx 3y ago
  It sounds like the same problem. I don't see, though, why the article you linked says it was "unfixable" for X11 because "clients relied on memory stored by the Xserver" when it then goes on to describe that Wayland has the same problem (storing state in the compositor) and "we just need to send the right amount of information to bring it in sync". Couldn't X11 be similarly brought into sync on reconnect? And aren't messages in X11 also mostly async (the other problem the article mentions) and it's just Xlib that (unlike XCB) turns them into synchronous calls?
  - orangeboats 3y ago
    They are not the same problem. The Qt one is related to the compositor crashing. Instead of dying immediately when the application loses connection to the compositor, it instead waits until the compositor recovers from the crash, and treats the compositor crash as a GPU reset. Wayland here has the advantage that it holds very little graphical context of the program, except the framebuffer and a few things, and the client controls everything else. As such, the recovery mechanism can be made _unidirectional_. The only thing the compositor needs to do, is to inform clients of the crash and the clients will handle the rest. The wayland-proxy one is related to the application not handling messages fast enough. In case it is not clear, a Wayland application typically crashes if it is disconnected by the compositor. The compositor disconnects because it cannot send any more messages to the application. It is usually due to the application hanging, making disconnection a reasonable action to take. But it could also just be a legitimate working application under heavy load, and this is where disconnection is actually _not_ desirable - this is what wayland-proxy fixes. However, one could also treat the forced disconnection as some kind of "controlled compositor crashing", and so Qt's approach could probably work for Firefox too. But the effects will be user-visible, since the browser windows will be closed and recreated again.

its the same "problem" that was fixed on QT? https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/ https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustnes... or it's other issue?

ptx 3y ago
It sounds like the same problem. I don't see, though, why the article you linked says it was "unfixable" for X11 because "clients relied on memory stored by the Xserver" when it then goes on to describe that Wayland has the same problem (storing state in the compositor) and "we just need to send the right amount of information to bring it in sync". Couldn't X11 be similarly brought into sync on reconnect? And aren't messages in X11 also mostly async (the other problem the article mentions) and it's just Xlib that (unlike XCB) turns them into synchronous calls?
- orangeboats 3y ago
  They are not the same problem. The Qt one is related to the compositor crashing. Instead of dying immediately when the application loses connection to the compositor, it instead waits until the compositor recovers from the crash, and treats the compositor crash as a GPU reset. Wayland here has the advantage that it holds very little graphical context of the program, except the framebuffer and a few things, and the client controls everything else. As such, the recovery mechanism can be made _unidirectional_. The only thing the compositor needs to do, is to inform clients of the crash and the clients will handle the rest. The wayland-proxy one is related to the application not handling messages fast enough. In case it is not clear, a Wayland application typically crashes if it is disconnected by the compositor. The compositor disconnects because it cannot send any more messages to the application. It is usually due to the application hanging, making disconnection a reasonable action to take. But it could also just be a legitimate working application under heavy load, and this is where disconnection is actually _not_ desirable - this is what wayland-proxy fixes. However, one could also treat the forced disconnection as some kind of "controlled compositor crashing", and so Qt's approach could probably work for Firefox too. But the effects will be user-visible, since the browser windows will be closed and recreated again.