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