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

[Sebastian Kügler]

> On Nov. 20, 2015, 10:14 a.m., Daniel Vrátil wrote:
> > src/backendmanager.cpp, line 361
> > <https://git.reviewboard.kde.org/r/126101/diff/3/?file=417472#file417472line361>
> >
> >     Instead of deleting the AbstractBackend manually here, you could let QPluginLoader do it by `mLoader->unload()`, then delete mLoader normally (not via deleteLater()). As a bonus it will unload the plugin binary from the process (just deleting QPluginLoader does not).

We can't do that actually, since it would mean a behavioural change from the out-of-process version. Shutting down the backend would effect the configs we handed out to become invalid, so we don't want to do this. (We also don't do this in the out-of-process version, but instead keep configs valid on the client side after shutting down the backen.)

I've changed the pluginloader to be deleted right away, however, not via deleteLater().


- Sebastian


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


On Nov. 20, 2015, 12:16 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. 20, 2015, 12:16 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 opt-in for 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.
> 
> Changes revolve around the ConfigOperations, the BackendManager (which "factories" the backends, either in- or out-of-process), and the plugin loading logic
> 
> 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 
>   autotests/testxrandr.cpp b9b838a 
>   backends/fake/fake.cpp 60264dd 
>   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/configoperation_p.h afdc462 
>   src/getconfigoperation.h c85bfaa 
>   src/getconfigoperation.cpp 22f92b4 
>   src/output.cpp bd381fa 
>   src/setconfigoperation.h 020a990 
>   src/setconfigoperation.cpp 6ea944f 
> 
> 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/20151124/98b68bf7/attachment.html>