On Wed, 29 Oct 2014 20:01:33 +0000 Daniel Stone <[email protected]> wrote:
> Hi, > > On Wednesday, October 29, 2014, Pekka Paalanen < > [email protected]> wrote: > > > On Tue, 28 Oct 2014 16:46:24 +0000 > > Daniel Stone <[email protected] <javascript:;>> wrote: > > > On 24 October 2014 11:18, Pekka Paalanen <[email protected] > > <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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
