dfaure added a comment.
I tested what happens in the current code when an idle job is killed. My
testcase was configuring to use KIO in componentchooser ("open http urls in an
application based on the contents on the URL") and then `kioclient5 exec
www.kde.org`. This puts the slave on hold while it emits the mimetype, while
KIO runs the associated application for that mimetype.
The idea was that the app can then use that job to resume the same transfer,
if the app uses KIO. In my testcase it's launching konqueror+webenginepart,
which doesn't use KIO, so the slave remains idle and gets killed later by
klauncher.
What happens just after KLauncher::idleTimeout deletes the slave is that the
slave goes to this code path inside mimeType() :
if (ret == -1) {
qDebug() << "read error";
exit();
}
So in my testcase at least, it goes to SlaveBase::exit(), which is how the
slave exits :)
You could try the same set of debugging statements in your testcase...
http://www.davidfaure.fr/2018/exit_debug.diff for kio and
http://www.davidfaure.fr/2018/kinit.diff for kinit.
Remember to restart kdeinit5 afterwards by typing kdeinit5 in a terminal -
but I guess you know this already ;-)
REPOSITORY
R303 KInit
REVISION DETAIL
https://phabricator.kde.org/D10824
To: chinmoyr, dfaure, #frameworks
Cc: #frameworks, michaelh
