[Kde-hardware-devel] Review Request 126101: allow loading backends in-process

[Sebastian Kügler]

> On Nov. 17, 2015, 9:55 p.m., Daniel Vrátil wrote:
> > src/backendmanager_p.h, line 130
> > <https://git.reviewboard.kde.org/r/126101/diff/1/?file=417202#file417202line130>
> >
> >     Why is this even a QHash? We don't want to run multiple backends at once, or do we? Wouldn't just holding pointer to the current backend be enough? Maybe even without the arguments...

The arguments are needed for the Fake backend, otherwise, loading a different config doesn't work, which breaks a bunch of tests. Instead of shutting down the backend, it's enough to re-init() it, which is what I'm doing here.

This bit could potentially make sense for other cases, for example passing the config for a wayland test server (which is what I'm doing for the wayland tests), and possibly also the WAYLAND_DISPLAY to use, as to avoid getting in the way of a running server.


- Sebastian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126101/#review88502
-----------------------------------------------------------


On Nov. 18, 2015, 12:32 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126101/
> -----------------------------------------------------------
> 
> (Updated Nov. 18, 2015, 12:32 a.m.)
> 
> 
> Review request for Plasma, Solid, Àlex Fiestas, Aleix Pol Gonzalez, Daniel Vrátil, and Martin Gräßlin.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> -------
> 
> This patchset adds in-process operation to libkscreen
> 
> purpose:
> - allow easier debugging
> - for some backends (qscreen, upcoming kwayland) the out of process operation is not necessary since these backends are well-shielded
> 
> This implementation is backwards compatible and should mean only minimal changes to running setups.
> 
> If the user exports KSCREEN_BACKEND_INPROCESS=1 before running, all operations will be done in process. Otherwise, the out-of-process mode is used.
> 
> The idea is that we use 
> The changes in the clients to use the in-process mode are to use ConfigOperation::create() and ConfigOperation::setOperation() to retrieve the get or set config jobs. The rest will be handled inside libkscreen.
> 
> Autotests should cover all the cases (and actually a few currently unsupported ones, such as using different backends in the same process).
> 
> Details on performance, etc.: http://vizzzion.org/blog/2015/11/wayland-and-libkscreen-benchmarks/
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 86a0965 
>   autotests/CMakeLists.txt 69af7f0 
>   autotests/testconfigmonitor.cpp a051226 
>   autotests/testinprocess.cpp PRE-CREATION 
>   autotests/testqscreenbackend.cpp da4dbae 
>   autotests/testscreenconfig.cpp ecbcedf 
>   backends/fake/fake.cpp 60264dd 
>   src/CMakeLists.txt 4b56b61 
>   src/backendlauncher/backendloader.cpp 52051df 
>   src/backendmanager.cpp ca9c746 
>   src/backendmanager_p.h c6418e2 
>   src/config.cpp 75d947d 
>   src/configmonitor.h b6f1189 
>   src/configmonitor.cpp a14bc70 
>   src/configoperation.h 2405d79 
>   src/configoperation.cpp 87fe141 
>   src/getconfigoperation.h c85bfaa 
>   src/inprocessconfigoperation.h PRE-CREATION 
>   src/inprocessconfigoperation.cpp PRE-CREATION 
>   src/output.cpp bd381fa 
>   src/setconfigoperation.cpp 6ea944f 
>   src/setinprocessoperation.h PRE-CREATION 
>   src/setinprocessoperation.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126101/diff/
> 
> 
> Testing
> -------
> 
> Added a ton of autotests, made sure all existing ones pass.
> 
> tried "KSCREEN_BACKEND_INPROCESS=1 kcmshell5 kscreen", all working as expected.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20151118/b6772afb/attachment-0001.html>