Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions

[David Edmundson]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141231/e2c47904/attachment.html>