<div dir="ltr"><div><br></div><div>Some months ago, I have discussed the Wayland Crash Scenario and how windows should reconnect to a newly started wayland either than being closed and losing the open work.</div><div><br></div>
<div>I discussed with zhasha and daniels and below there is a resumé of some points that may be useful:</div><div><br></div><div>...</div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><daniels></div>
<div>wayland doesn't really have any state to save, the state to save lies in the apps - and as you've said, well-behaved apps like chromium do that automatically now</div></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<zhasha> Wayland needs to save its state somewhere it can be quickly retrieved</div></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><daniels> wayland itself has very little state to save though</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><zhasha> true but it still needs to continuously save it</div><div>...</div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><boulabiar> daniels, they don't need to save them, they need to tell apps to do a redraw</div><div><zhasha> and how the hell does it know its clients surfaces when it just lost all its memory+state?</div>
<div><daniels> boulabiar: yeah, but wayland doesn't connect to apps, the apps connect to wayland. so, if wayland crashes and restarts, the apps are going to know wayland's crashed when they reconnect.</div>
<div><zhasha> now you're venturing into the realm of "clients must support it" which they can do no matter what you do server-side</div><div><boulabiar> zhasha, the client memory are they stored in wayland or in that client process ?</div>
<div><zhasha> the surface is created by the client and stored in the client</div><div><boulabiar> so</div><div><zhasha> but how does wayland know it's there if it just lost all state?</div><div><boulabiar> zhasha, how much he need to store as a log, to recover that later ?</div>
<div><zhasha> you need to do 2 things:</div><div><zhasha> 1) save state *on every change* somewhere</div><div><zhasha> 2) make the transport (usually a socket) persist</div><div><zhasha> then when your server crashes, the clients won't be disconnected and the state can be recovered</div>
<div><daniels> the only interesting thing you could do is come back up with the exact same surfaces</div><div><daniels> but you probably don't want to do that, as the apps themselves may not have saved state</div>
<div><zhasha> and personally I think it's more trouble than it's worth, when pretty much all crashes (especially after wayland goes stable) can pretty much be traced back to the 3D driver</div><div><daniels> so you might just be throwing up a picture of your browser session where your browser has in fact vanished, or is doing something else</div>
<div><daniels> all the interesting state is in the clients, it's them that need to save the state</div><div><zhasha> daniels: no really, you can freeze the process, or alternatively just queue all their protocol requests</div>
<div><daniels> if apps were more robust against servers disappearing - which they can be with xcb, but no-one cares enough to port their toolkits/apps to it - then even x crashing wouldn't be a problem, because the apps would just reconnect and carry on</div>
<div><boulabiar> daniels, if there would be apps running on wayland, then toolkits need first to be ported anyway, we can just say be more robust because you're doing the work in all cases</div><div><daniels> boulabiar: yep.</div>
<div><boulabiar> and to automatically restart wayland</div></div><div><br></div><div><br></div><div><br></div><div>According to this discussion xcb handles server disappear.</div><div><br></div><div>i</div><div><br>
</div></div>