Re KIO workers

Alexander Lohnau alexander.lohnau at gmx.de
Sat Jun 5 17:51:58 BST 2021


On Saturday, 5 June 2021 17:51:18 CEST David Faure wrote:
> On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote:
> > Do KIO slaves still need the klauncher/kinit loading mechanism?
>
> No. My request for developers to test KIO_FORK_SLAVES=1
> for daily use is so that apps fork kio worker processes directly, without
> going via klauncher/kinit. BTW it seems to work fine. I wonder if we should
> toggle that in 5.84, as part of the incremental move to the KF6 world.
>
> > or could
> > that be replaced by json metadata based plugin loading as well?
>
> Err, that's an orthogonal question.


That was meant regarding https://invent.kde.org/frameworks/kio/-/blob/master/src/
kioslave/kioslave.cpp#L73[1], similar to https://phabricator.kde.org/T13808[2].

But because SlaveBase is not a QObject we could not do this during KF5 times  easily. It
was just an idea :)

>
> When not going via klauncher/kinit, the app first launches the kioslave5
> process, which then loads the .so with the kio worker plugin. As you can
> see from your process list:
>
> PREFIX/lib64/libexec/kf5/kioslave5 PREFIX/lib64/plugins/kf5/kio/file.so file
>  local:/run/user/1000/kded5ymjnPa.3.slave-socket
>
> That .so is determined by slave.cpp using
>          QString lib_path = KPluginLoader::findPlugin(_name);
> which I believe means it finds the plugin by filename, no .protocol file
> needed and no json metadata needed, right?
>
> > - is the performance benefit of kinit still relevant there?
>
> We decided it wasn't. For KIO workers it was never measured anyway.
>
> > - for in-process KIO that would be needed anyway
>
> That would remove the separate process (kioslave5) from the equation
> but that's unrelated to plugin loading.


Regards
Alex


--------
[1] https://invent.kde.org/frameworks/kio/-/blob/master/src/kioslave/kioslave.cpp#L73
[2] https://phabricator.kde.org/T13808
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210605/47af1b7e/attachment.htm>


More information about the Kde-frameworks-devel mailing list