<div dir="auto">Hi everyone,<div dir="auto"><br></div><div dir="auto">wegen Florian and me started working on session a few months ago we also expected it to work that way.</div><div dir="auto">However we learned that there were two internal modes: saved sessions and the fallback session.</div><div dir="auto">Irritatingly the fallback session was the de facto standard or default that everyone used/uses who doesn't save his/her session.</div><div dir="auto"><br></div><div dir="auto">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"...</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">My feeling is that this may simply have been ignored in the past or maybe the impact of those races has increased with Gtk3.</div><div dir="auto"><br></div><div dir="auto">I hope this helped to clarify the current situation or status of session!</div><div dir="auto">Cheers</div><div dir="auto">Simon</div><div dir="auto"><br></div><div dir="auto"><br></div></div><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, 18:11:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
On Sat, 20 Jul 2019 at 17:38, Olaf Hering <<a href="mailto:olaf@aepfle.de" target="_blank" rel="noreferrer">olaf@aepfle.de</a>> wrote:<br>
><br>
> A few weeks, or perhaps months, ago the session startup code was updated to use "priority groups". Since this time there are notable delays during fresh boot. I just checked the wall clock. It took about 16 seconds from visible X11 mouse cursor until the first app windoes from ~/.config/autostart appeared.<br>
><br>
> I wonder if there is room to improve this. Does xfce4-session actually wait for events from the apps launched via xfce4-session.xml? How does it decide that the next priority group should be processed?<br>
><br>
> Maybe xfce4 apps could send notifications back to xfce4-sessions that their own init process is done, so that xfce4-session could move on?<br>
<br>
That's how I expected it to work as well, but my observation tend to<br>
show not even the priority is respected, which is ... confusing and I<br>
think is causing most of the pain we are experiencing with the races<br>
at startup.<br>
<br>
See <a href="https://bugzilla.xfce.org/show_bug.cgi?id=15712" rel="noreferrer noreferrer" target="_blank">https://bugzilla.xfce.org/show_bug.cgi?id=15712</a> and<br>
<a href="https://bugzilla.xfce.org/show_bug.cgi?id=15725" rel="noreferrer noreferrer" target="_blank">https://bugzilla.xfce.org/show_bug.cgi?id=15725</a><br>
<br>
There is something seriously fishy there...<br>
<br>
Cheers,<br>
Olivier<br>
_______________________________________________<br>
Xfce4-dev mailing list<br>
<a href="mailto:Xfce4-dev@xfce.org" target="_blank" rel="noreferrer">Xfce4-dev@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev" rel="noreferrer noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a></blockquote></div>