GSoC: Hot-Replace Server

[Mohamed Ikbel Boulabiar]

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.

I discussed with zhasha and daniels and below there is a resumé of some
points that may be useful:

...
<daniels>
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
<zhasha> Wayland needs to save its state somewhere it can be quickly
retrieved
<daniels> wayland itself has very little state to save though
<zhasha> true but it still needs to continuously save it
...
<boulabiar> daniels, they don't need to save them, they need to tell apps to
do a redraw
<zhasha> and how the hell does it know its clients surfaces when it just
lost all its memory+state?
<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.
<zhasha> now you're venturing into the realm of "clients must support it"
which they can do no matter what you do server-side
<boulabiar> zhasha, the client memory are they stored in wayland or in that
client process ?
<zhasha> the surface is created by the client and stored in the client
<boulabiar> so
<zhasha> but how does wayland know it's there if it just lost all state?
<boulabiar> zhasha, how much he need to store as a log, to recover that
later ?
<zhasha> you need to do 2 things:
<zhasha> 1) save state *on every change* somewhere
<zhasha> 2) make the transport (usually a socket) persist
<zhasha> then when your server crashes, the clients won't be disconnected
and the state can be recovered
<daniels> the only interesting thing you could do is come back up with the
exact same surfaces
<daniels> but you probably don't want to do that, as the apps themselves may
not have saved state
<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
<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
<daniels> all the interesting state is in the clients, it's them that need
to save the state
<zhasha> daniels: no really, you can freeze the process, or alternatively
just queue all their protocol requests
<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
<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
<daniels> boulabiar: yep.
<boulabiar> and to automatically restart wayland



According to this discussion xcb handles server disappear.

i
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110405/710438c6/attachment.htm>