<div dir="auto"><div>Hi Olivier,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Olivier Fourdan <<a href="mailto:fourdan@gmail.com">fourdan@gmail.com</a>> schrieb am Sa., 20. Juli 2019, 21:43:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Simon<br>
<br>
On Sat, 20 Jul 2019 at 20:58, Simon Steinbeiss <<a href="mailto:simon@xfce.org" target="_blank" rel="noreferrer">simon@xfce.org</a>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> wegen Florian and me started working on session a few months ago we also expected it to work that way.<br>
> However we learned that there were two internal modes: saved sessions and the fallback session.<br>
> Irritatingly the fallback session was the de facto standard or default that everyone used/uses who doesn't save his/her session.<br>
><br>
> Now the thing about the fallback session was that it just started all applications at once, irrespective of the priority group. The reason documented in the code was that this was "merely the fallback"...<br>
> So we dug deeper trying to understand what could be improved. One of the major limitations of not using a saved session (which always respected the priority groups) is that the unique application/process id that the session uses to identify a process to see whether it can start the next one is generated once the app is running. So at the first session start the session manager doesn't know anything about the apps apart from some metadata like start command and name. This is how it always is for the fallback session - or one should probably rename it to default session.<br>
> So we introduced the - rather limited - version of prio groups for the default session, without being able to properly trace an app or its exact status, but at least launching programs in batches, with autostart apps from the user coming last.<br>
><br>
> In theory one could probably change the approach in general and just so what the default session does "once" and then stick to that, but that would have implied even bigger code changes to something I don't know enough about (a certain type of session management also seems to have been deprecated upstream at gnome/Gtk).<br>
><br>
> The idea of doing this prio groups approach was that we would reduce race conditions and indeed a few have already done away (e.h. between the panel and xfsettingsd), but I guess a few others are still out there.<br>
> My feeling is that this may simply have been ignored in the past or maybe the impact of those races has increased with Gtk3.<br>
><br>
> I hope this helped to clarify the current situation or status of session!<br>
<br>
For first time users (and those who do not save their session, ever),<br>
the fallback *is* the session, so calling it fallback is misleading,<br>
I'd rather call it the “default” session.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree and hope that much was clear from my email. I didn't change the name in the code because it was all over the place and I didn't want to interfere with old xfconf settings/paths that also contain the reference to "fallback".</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I understand the recent changes are made to turn the “default” session<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
into the same sort of session as a saved one.<br>
<br>
The problem with priority is that people expect to do what is written<br>
on the tin, ie start and make sure all components from a given<br>
priority are started before starting the components from a lower<br>
priority.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">While I agree in general the priority feature was always "written on the tin", just look at what's stored in xfconf as part of the fallback session. No clue why the priority was stored there at all, it was simply misleading...</div><div dir="auto">Also the apps are started by priority group and not simply "all at once" anymore. However there's no way of knowing if or when startup was complete.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For this to work, xfce4-session should wait for each component of a<br>
given priority to register before spawning the new group - Without<br>
such a mechanism, there is no way the priority can be guaranteed to be<br>
respected, every component will take random time a to start, that's<br>
unavoidable.<br>
<br>
Of course, xfce4-session would implement some sort of timeout, to<br>
avoid one component from stalling the entire process for too long.<br>
<br>
Failing that, we cannot avoid the various race conditions we face now.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree and that's why I wrote it only *reduces* race conditions in its current state. (I would have hoped that the current state of launching apps in the correct order at least and grouping that order would avoid most - or ideally even all - race conditions. Unfortunately it seems that we're still facing them so maybe the improvement was smaller than anticipated.)</div><div dir="auto"><br></div><div dir="auto">However I'm not sure if and how it's possible to do it properly. Maybe someone else can try to push it a little further.</div><div dir="auto"><br></div><div dir="auto">Personally I would recommend that those who experience races frequently or can consistently reproduce them save a clean session once to see if that actually fixes all issues. (It's possible that the session manager is not directly responsible for all of them.)</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Simon</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>