We need clients that can survive an X restart. [LWN.net]

We need clients that can survive an X restart.

Posted Jan 19, 2007 18:43 UTC (Fri) by AJWM (guest, #15888)
In reply to: LCA: Andrew Tanenbaum on creating reliable systems by drag
Parent article: LCA: Andrew Tanenbaum on creating reliable systems

> when the drivers in Linux bork, X restarts.

The problem is, that pretty much takes all the X clients with it, so you've lost your whole session anyway.

Now, arguably that's the fault of the client(s) rather than the X server, but I've yet to see an X client program written that could gracefully recover (ie to the point of picking up exactly where it left off) if its X display was yanked out from under it and restarted. It's been long enough since I programmed at the Xlib level that I don't recall how much state (of windows, etc) is in the server vs the client (via the X libraries), but I imagine that enough state _could_ be kept in the client (again, courtesy of the xlib) to redisplay to the new X server everything that was there when the old one borked.

It'd be an interesting and non-trivial programming exercise, but a massively useful one. (Nothing worse than having numerous windows open, having your X display lock up, and knowing that the only thing you can do is blow it all away even though the client programs are still perfectly OK - or will be until their display connection is killed.)

(Log in to post comments)

We need clients that can survive an X restart.

Posted Jan 20, 2007 0:31 UTC (Sat) by drag (subscriber, #31333) [Link]

Well I would think that compositing would make it easier to make things stateless, since windows and such are not rendered on the actual display but in off-screen buffers.

I'd think you'd just have to keep those off-screen buffers alive and when the main display comes back up then you "re-composite" them.

Maybe you need a different thread for the application management vs the part of the X server that does the actual rendering or something, I don't know.

We need clients that can survive an X restart.

Posted Jan 20, 2007 8:21 UTC (Sat) by cworth (subscriber, #27653) [Link]

> GTK+ has had for years the ability to disconnect from one display and
> reconnect to another, which also means that you can connect it to a dummy
> display while your real display restarts.

There is a missing piece here though. The GTK+ code can successfully
migrate an X connection through a client-initiated disconnect. But it
turns out that design flaws in Xlib make it impossible for a client
to cleanly recover from an X server that disappears out from under the
client.

I've actually looked into what it would take to retrofit Xlib to add
what's missing. It'd be possible, but it would require a programmer
with a stronger constitution than I have to wade through the Xlib
internals to make the fix. And then one would still need to fixup
GTK+ to properly respond to the new XServerDisconnected event that
would have to be added.

Meanwhile, a more realistic approach is to get toolkits to switch to
XCB which doesn't suffer from the same shortcoming as Xlib in this area.

> However this toolkit capability has been long neglected by application
> writers.

I agree that there are some interesting aspects of migrating applications
from one X server to another that applications aren't taking advantage of.

But for the idea of replacing an X server for an entire session---I'd much
rather that be something that not require any application knowledge at all.
That's a much quicker route to making it work reliably for as many
applications as possible.

-Carl

We need clients that can survive an X restart.

Posted Jan 22, 2007 5:19 UTC (Mon) by elanthis (guest, #6227) [Link]

With XCB around, is it really necessary to retrofit Xlib with those changes? Either way, client apps will need to be updated, and XCB brings a lot of other benefits with it, no? Most apps use a toolkit, so once you get the major ones ported (including whatever today's popular Motif clone is, and Tk) you should be set.