[PATCH Weston 1/1] desktop-shell: implement autolaunch

[Pekka Paalanen]

On Wed, 29 Oct 2014 20:01:33 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On Wednesday, October 29, 2014, Pekka Paalanen <
> pekka.paalanen at collabora.co.uk> wrote:
> 
> > On Tue, 28 Oct 2014 16:46:24 +0000
> > Daniel Stone <daniel at fooishbar.org <javascript:;>> wrote:
> > > On 24 October 2014 11:18, Pekka Paalanen <pekka.paalanen at collabora.co.uk
> > <javascript:;>>
> > > wrote:
> > I think we all forgot a tiny detail here.
> >
> > weston_client_start() is a compositor internal function, while this
> > patch is modifying weston-desktop-shell client.
> 
> 
> Egads, I'd completely missed that, and assumed it was compositor rather
> than shell.
> 
> Any reason to have it like that? Compositor seems more natural to me ...

The compositor could do the autolaunch, but we also have the panel
launch buttons, that need to be executed in weston-desktop-shell. And
autolaunch and the panel launchers are very similar, but not too similar
to the in-weston launching.

But I see what you might be getting at: if weston-desktop-shell does
autolaunch, and it respawns, it will autolaunch everything again. Not
good.

So we'd probably need autolaunch in the server side indeed. Then we
could put the command line parsing into env/cmd/args in libshared to
share that with weston-desktop-shell. Keep all the respawn logic inside
the compositor and maybe refactor that into some shared weston core
code.

Below I'll attach what I had written earlier but not sent, because
then I realized the server vs. weston-desktop-shell thing. If we do
autolaunch in the server, the below more or less applies again.

**

Okay, if Fred or someone actually has time to do all that refactoring
and writing, it's cool. It's just more work than simply adding
autolaunch, which was the original goal here.

So, we need to cater for two different cases:
a) start a client with a pre-made connection (set WAYLAND_SOCKET), and
b) start a new arbitrary process (do not set WAYLAND_SOCKET).

By refactoring, both cases should then have customizable environment,
and maybe optional respawn with conditions to give up if the process
exits too often.

Custom environment may come from weston.ini in case of manual
and auto-launchers, or hardcoded in plugins (currently not done).

Respawn needs the following parameters:
- is respawn triggered by wl_client destruction or SIGCHLD
- when to give up
(- delay to respawn?)

If I understood right, you suggested that respawn would be limited to
observing the wl_client, which practically means purely case a). That
should work, I think.

Manual launchers (the panel buttons) should never support respawn.

As a detail, case a) function will also need a hook that delivers the
new wl_client to the calling code when respawn happens. Otherwise e.g.
shell.c would not get the new authorized connection if
weston-desktop-shell crashes. We will also need a way to stop
respawning, e.g. shell.c uses that during shutdown when it deliberately
disconnects weston-desktop-shell.

When to give up?

The current logic for weston-desktop-shell is that if it crashes during
the first 30 seconds from session start, respawn will not be attempted,
and weston is shut down instead. Later, if weston-desktop-shell crashes
more than 5 times within 30 seconds, it gives up but does not exit
Weston, since other clients may still work.

**

Do we want to support autolaunching anything else than Wayland clients
directly? If not, then case b) can be dropped, which would be nice.

Can the weston-desktop-shell respawn/shutdown logic be supported by a
generic respawn code, or is it too complicated to be worth it? Maybe
e.g. weston-keyboard has a less complicated respawn logic that could
share with autolaunch.

Details... up to the person writing the code. We can then see how it
looks like. I would just want to avoid designing a big and complicated
launching and respawning framework just to cater the need of one
special case (weston-desktop-shell). If we can do with a simple design
otherwise but force weston-desktop-shell logic still be separate, that
is fine. Simplicity should be the driving goal in the code design. ;-)


Thanks,
pq