> On Dec. 30, 2014, 2:06 p.m., Daniel Vrátil wrote: > > I guess the code is note perfect and there are still race conditions, but > > this is a good step in the right direction, so let's ship it. I'll think > > about the lockfile solution, or some other and try to implement it (once > > I'm back at work). > > > > The one-service-multiple-objects solution would not work, since you can't > > have multiple processes owning the same DBus service name, and I don't want > > to run multiple backends in one process.
Why would you ever want to run multiple backends at the same time? (outside of testing, which could be done on a private DBus session) - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/#review72782 ----------------------------------------------------------- On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121710/ > ----------------------------------------------------------- > > (Updated Dec. 28, 2014, 10:33 a.m.) > > > Review request for Plasma, Solid and Daniel Vrátil. > > > Repository: libkscreen > > > Description > ------- > > Avoid risk of starting two kscreen_launchers at the same having a race > condition. > > There were three possible bugs: > CheckIsAlreadyRunning tried to register a service and check if it worked. > This could clash with another process checking at the same time. Causing them > both to fail saying another is running > Similarly, a daemon doing actual registering could clash with another daemon > just checking if the name is free, and then it would fail saying we can't > init() > > There was also a risk that two launchers pass the check that nothing is > running, then both try to activate a session. DBus server handles this fine > and one will gracefully fail. Without this patch the second launcher would > just die without returning the path of the service that was activated causing > the relevant app to do nothing. > > > -- > > IMHO, you'd be better off having a fixed service name and using DBus > activation for exactly these reasons. > You could put the different backends at different object paths, and have a > method on the root object that says which object path to use rather than > using the stdout of a launcher. That's a discussion for another day though. > > > Diffs > ----- > > src/backendlauncher/backendloader.cpp e7da8cd > src/backendlauncher/main.cpp f8bf323 > > Diff: https://git.reviewboard.kde.org/r/121710/diff/ > > > Testing > ------- > > Send it to bshah. Plasmashell started for him. Previously it didn't. > > > Thanks, > > David Edmundson > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
