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
compositor.
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
simultaneously.
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
connection.
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