Post AzCVPplI66KC3XF2qe by Merovius@chaos.social
(DIR) More posts by Merovius@chaos.social
(DIR) Post #AzCORGXVKCuriRWqRs by Merovius@chaos.social
2025-10-14T11:04:44Z
0 likes, 0 repeats
@emersion @zekjur It's good to see that there is work happening on this. The PR is still behind what I would like - it shouldn't require an extra tool and it should be possible to do a restart transparent to clients, AIUI - but it would be progress.That X is synchronous and thus harder to restart transparently is a good point I haven't considered.
(DIR) Post #AzCORHlMm9bBVj1Qh6 by shironeko@fedi.tesaguri.club
2025-10-14T11:51:15.629556Z
0 likes, 0 repeats
@Merovius @emersion @zekjur application probably always needs to be involved otherwise compositor need to keep all that old state and probably will just crash again
(DIR) Post #AzCPW38sf8jHZEr9U0 by Merovius@chaos.social
2025-10-14T11:57:58Z
0 likes, 0 repeats
@shironeko I'm not sure. I admit that I don't know enough about Wayland, but ISTM there is a wide gulf between "keep no state" and "keep everything" and somewhere in there is a useful middle ground.
(DIR) Post #AzCPW4BOnGL0nL2g2y by shironeko@fedi.tesaguri.club
2025-10-14T12:03:22.035114Z
0 likes, 0 repeats
@Merovius if the compositor author could figure out what state they need to keep and what state they can throw away, they're probably better off just punting those unnecessary states to a separate process and not have the compositor crash in the first place.
(DIR) Post #AzCQ4DgnxGLO7n19Pc by Merovius@chaos.social
2025-10-14T12:06:26Z
0 likes, 0 repeats
@shironeko Okay. Not that I find that convincing, but "do that, then"? I mean, I just don't want to have to start from basically a reboot every ten minutes. I'm not terribly worried about how that is implemented.
(DIR) Post #AzCQ4EcwT6qf26Da1w by shironeko@fedi.tesaguri.club
2025-10-14T12:09:32.450893Z
0 likes, 0 repeats
@Merovius what do you mean? I'm just saying compositor crash recovery need to involve the applications (just like GPU crashes) aka those robustness protocol that's linked by @emersion
(DIR) Post #AzCQtGIo02jazt8Auu by Merovius@chaos.social
2025-10-14T12:14:53Z
0 likes, 0 repeats
@shironeko And I don't see what would prevent it from being transparent. Unless there is some kernel state that is both shared between application and compositor *and* is lost during an `exec`.There very well might. I don't know of any, but I'm not an expert.
(DIR) Post #AzCQtHpSK8RhjRPlRo by shironeko@fedi.tesaguri.club
2025-10-14T12:18:45.906273Z
0 likes, 0 repeats
@Merovius I'm not saying it can't be preserved, I'm just saying there's a high likelihood that those states are what led to the crash in the first place. what's a transparent recovery good for if it can only recover 10% of the crashes and the other 90% need application help anyway?
(DIR) Post #AzCRUacfPbYmjaDi8e by Merovius@chaos.social
2025-10-14T12:20:51Z
0 likes, 0 repeats
@shironeko It would mean that in 10% of cases, I don't need to start from scratch. And if the particular problem that causes these crashes for me is one of those, it means that in 100% of cases I don't need to start from scratch.Not that the 10% seems realistic to me.
(DIR) Post #AzCRUbjnGar4ByYusy by shironeko@fedi.tesaguri.club
2025-10-14T12:25:30.671286Z
0 likes, 0 repeats
@Merovius how is the compositor supposed to know which case the crash belongs to? why not just have the application send the nessesary info to the compositor so compositor crash recovery works 100% of the time?
(DIR) Post #AzCUMBTrJ03eIrmecS by Merovius@chaos.social
2025-10-14T12:36:53Z
0 likes, 0 repeats
@shironeko 1. It doesn't need to. It just tries to restart and if it crashes again, nobody's worse off. And if it doesn't, some people are better off. Make a restart counter/timer part of the state to prevent crashloops.2. Because there are vastly fewer compositors than clients. It's less work. And it's a better experience if *all* applications survive the restart, not just those that handle it correctly.
(DIR) Post #AzCUMClyV88wJLGdUm by Merovius@chaos.social
2025-10-14T12:37:46Z
0 likes, 0 repeats
@shironeko It's telling, that you seem to believe applications are correct 100% of the time, while compositors can be correct only 10% of the time. That's, in my experience, exactly the wrong way around.
(DIR) Post #AzCUMDi70yeDDeT476 by shironeko@fedi.tesaguri.club
2025-10-14T12:57:33.735989Z
0 likes, 0 repeats
@Merovius idk if you are intentionally obtuse or not, we are talking about compositor crash here right? so it is given that compositor is faulty?
(DIR) Post #AzCUOnbEYEDN6eTpbc by shironeko@fedi.tesaguri.club
2025-10-14T12:58:05.912298Z
0 likes, 0 repeats
@Merovius and where does that 10% come from?
(DIR) Post #AzCUqsJ0eD6noILMPY by Merovius@chaos.social
2025-10-14T13:00:40Z
0 likes, 0 repeats
@shironeko Yes it is a given that there is a bug in the compositor.The 10% come from here: https://fedi.tesaguri.club/notice/AzCQt33swdAIH4x8Gu
(DIR) Post #AzCUqtHd0pb8qIhltg by shironeko@fedi.tesaguri.club
2025-10-14T13:03:09.146197Z
0 likes, 0 repeats
@Merovius that 10% is also compositor, just some handwaved percentage of states that are unrelated to clients. wth
(DIR) Post #AzCVPplI66KC3XF2qe by Merovius@chaos.social
2025-10-14T13:08:03Z
0 likes, 0 repeats
@shironeko yes, which is why I said “you seem to be assuming compositors can only be correct 10% of the time”.I would expect compositors to be largely more robust than clients. As they are only written by people with certain skills, are more heavily tested, just generally get more work. While roughly everybody might put any amount of effort into a client.So I would assume a compositor approach to be significantly more robust than relying on the client.
(DIR) Post #AzCVPqVNKlBiMSnqgC by shironeko@fedi.tesaguri.club
2025-10-14T13:09:28.119011Z
0 likes, 0 repeats
@Merovius okay I give up, you are talking about something completely unrelated to what I wrote. have a good day