[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re KIO workers
From:       David Faure <faure () kde ! org>
Date:       2021-06-05 15:51:18
Message-ID: 2559817.BddDVKsqQX () asterixp15
[Download RAW message or body]

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.

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.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5


[prev in list] [next in list] [prev in thread] [next in thread]