On my Windows machine, when Windows Explorer (the shell) crashes, it "gracefully" recovers, leaving my running applications in tact.
On Fedora, when gnome-shell (not sure exactly which component) crashes, it takes down every single application I was running, and forces me to log in again and start from scratch. I lose all work from all open graphical applications.
Is it possible to make it recover more gracefully?
Yes, it'd be great to fix the crashes entirely, but that's probably unrealistic. Seems more feasible to enable graceful recovery in most cases.
It's probably best to file an upstream ticket for this. I had a look but couldn't find one.
Note that this is a really hard thing to do - the problem is that there is shared state between the wayland compositor and the client, so if the compositor crashes, you have to get them back onto the same page. And the crash might occur at any point.
Different approaches that have been discussed: * Try to make clients robust against the compositor vanishing * Add a thin "proxy" compositor between the real compositor and the clients * Split the shell into two processes - a lightweight compositor+scene graph, and the heavyweight window-manager+shell * Split the user interface pieces of the shell - the menus, activities overview, etc, into separate processes from a core window-manager+compositor+scene-graph
Any one of these is easily 6 months - 1 year of work for an experienced developer - and you might well spend 6 months on one of these approaches and end up at a dead end.
(If I had to pick one of these, I'd probably be attracted to the third approach - which is vaguely like Android's SurfaceFlinger - but there is a pile of hard questions there - one of them being that then the shell and the compositor are sharing complex state which you have to recover from a crash at an arbitrary point. If you can't do that, then you haven't gained anything.)
Anyways, all of this to say that it's not an undiscussed topic, but it's a hard one. An upstream ticket might be useful to just record that the Mutter developers know it's an issue.
I don't think this is going to be resolved successfully by the Working Group. A major engineering effort like this needs to happen upstream. Sorry.
Metadata Update from @catanzaro: - Issue close_status updated to: Deferred to upstream - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.