Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

We need clients that can survive an X restart.

Posted Jan 19, 2007 21:27 UTC (Fri) by jwb (guest, #15467)
In reply to: We need clients that can survive an X restart. by AJWM
Parent article: LCA: Andrew Tanenbaum on creating reliable systems

Actually X11 is (used to be) stateless. These days with backing stores and compositing it's not quite true. 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. However this toolkit capability has been long neglected by application writers.

(Log in to post comments)

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.