|
|
Log in / Subscribe / Register

Different state between sessions and within sessions

Different state between sessions and within sessions

Posted Jan 28, 2026 18:57 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Architecture / Modularization by rgmoore
Parent article: Xfwl4: the roadmap for a Xfce Wayland compositor

It's completely different state, and there's very little overlap.

The in-session restart state wants to start from a connected client socket FD that you can duplicate and pass back to the restarted compositor, and then send it a serialized lump of state (including DMABUF FDs) that allows the compositor to "fast-forward" to exactly the place the communications were in before the client crashed, as-if all the previous communications with the client had happened with this instance of the compositor. If it all works, the client is completely unaware of the crash - and if the client quit or crashed between the compositor restarting, and you sending this state to it, you just drop the client (that is, after all, what you'd have done if the compositor hadn't crashed).

The between-session restart state wants to know how to launch the client, and what to send the client to get it to issue appropriate protocol requests to (e.g.) reopen windows that you can then position where they were before. But that's completely different metadata, with the overlap basically being that both include positions and sizes in them.

For example, the in-session restart state might say "there is a monitor attached to DP-3, which is at 0x0 and size 3840x2160, scale factor 125/100", or "FD 123 has surface ID 0x12345678 open, contents provided by the DMABUF on FD 2155 using DMABUF, and attached as a sub-surface of 0x7714 at location 120x340. Surface 0x7714 is a top-level surface, at 10x10 from the top-left of DP-3". The compositor follows all of this metadata to restore state to where it was when it crashed, then does things like "DP-3 is disconnected, rearrange windows".

The between-session metadata might say "start browser-binary, and ask it to open https://lwn.net/ attaching metadata token browser-restart-lwn-net. When a top-level surface is created with attached metadata token browser-restart-lwn-net, move it to 10x10 from the top-left of the Dell U3216Q and make it 2000 pixels wide by 2000 pixels high, resizing and moving as appropriate if that monitor is not connected any more".


to post comments

Different state between sessions and within sessions

Posted Jan 28, 2026 21:16 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Thank you for the detailed response. It makes total sense now.

I also want to thank LWN for producing the kind of place where my question was treated as a serious request for information. I feel like if I asked the same kind of question in a lot of places, people would treat it as a challenge to their competence, resulting in a lot of unproductive bickering. It's so refreshing to have a place where that rarely happens and the moderators are quick to step in if it does.

Different state between sessions and within sessions

Posted Jan 29, 2026 9:13 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

What is probably closely related to the crash recovery state is the state required to restart for the purposes of upgrading the compositor without restarting all the applications too. That one might need a bit more information on the exact data types in use though so it can detect when something changed and needs migration between versions of the same data.

Different state between sessions and within sessions

Posted Jan 29, 2026 10:23 UTC (Thu) by farnz (subscriber, #17727) [Link]

It is - it's also a subset of the state that wprs has to maintain, since it knows whether the compositor can recover state implicitly, or has to have explicit protocol to recover a given piece of state.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds