Wayland hot-replace server?

Bill Spitzak spitzak at gmail.com
Sun Mar 6 11:41:08 PST 2011

I think the original poster's idea is exactly what is needed:

I the compositor crashes or exits, the clients will detect this. It is  
then the client's job to find a new compositor and recreate their  
state on the new one. Most toolkits store quite enough redundant  
information that they should be able to do this, I would suspect the  
biggest trick will be to completely forget any ids from the previous  

The way the client will detect when the new compositor is available is  
by following exactly the same rules they use when the first start up  
to locate the compositor. If for instance when a client starts it  
attempts to open a named pipe, this is exactly what it will do after  
the previous compositor exits. If it fails to open it probably should  
try repeatedly with a timeout between each try, and only exit with an  
error after a very long time (30 seconds or so). This will give time  
for the compositor to restart, and would also solve the current  
problem where you can't launch a compositor and a bunch of clients  

Besides handling crashing, this should also be the way to switch  
compositors. A compositor could actually force a client to a different  
compositor by first modifying the client's environment in whatever way  
is needed so it will connect to the new one, then closing the  

On Mar 6, 2011, at 10:04 AM, Marty Jack wrote:

> On 03/06/2011 12:41 PM, nerdopolis wrote:
>> Hi.
>> I just want to bring this up for early consideration:
>> It seems that many things in Wayland will be determined by they  
>> type of compositor server you are running, such as if you want to  
>> have a tiling window manager in Wayland, or one that has other  
>> features.
>> My question is that will users be able to have the ability to  
>> change their Wayland servers on the fly? not only would such a  
>> thing allow the users to change functionality, but it will also  
>> help in the case if the Wayland server goes down, where the session  
>> is not lost.
>> Will this have to happen in the apps themselves? If so, how would  
>> the apps "know" that the socket (or maybe even a new socket) is  
>> available for reconnect?
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> An interesting point.  A parallel to <window-manager> --replace, and  
> probably something that users would want to do while they are  
> experimenting with different looks.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

More information about the wayland-devel mailing list