[KDE/Mac] Potential blocker in kdeinit5 and klauncher5 on OS X

[Ian Wadham]

Hi guys, especially David,

Yesterday David wrote and I replied:
> I was wondering why klauncher was not in the list, after all it's the one 
> writing to that socket, to tell kinit what to do. The answer: because 
> klauncher is started by kdeinit forking and passing the file descriptor as 
> "command-line" argument (argv). So that explains it ;)

    "Watch this space… There was a glitch with that "argv" in KDE4 + OSX.  I will
      check if it is still there in Frameworks + OSX."

Well, yes.  I checked (by reading the code) and the glitch is still there, as far
as I can see.  Specifically, when you run kdeinit5 on OSX, I think you will find
that it blocks in its "int main(int argc, char **argv)" program, at or near line 1782,
where the code says:

    if (launch_klauncher) {
        start_klauncher();
        handle_requests(d.launcher_pid); // Wait for klauncher to be ready
    }

In KDE 4 on OS X, kdeinit4 definitely blocks at that point, because KLauncher
never replies on kdeinit4's socket, whose FD number is passed as an argv by
the start_klauncher() procedure.  I tested and verified that back in July-August
last year.  Today I am fairly sure the problem is still there in Frameworks.

Why no reply from KLauncher?  On OSX (and Windows), KLauncher has the
macro USE_KPROCESS_FOR_KIOSLAVES defined in klauncher.h.  In
klauncher.cpp on Frameworks, that causes QProcess to be used to start
processes.  Nothing wrong with that…

A side-effect is that code is compiled conditionally which also ignores the FD that
is passed by kdeinit4/5 and fails to store it in its private data.  Consequently there
can be no back-communication from klauncher5 to kdeinit5.

That might account for a problem Jeremy is having.

When KLauncher has started successfully, it executes this code, circa line 160
of klauncher.cpp:

#ifdef USE_KPROCESS_FOR_KIOSLAVES
    qCDebug(KLAUNCHER) << "LAUNCHER_OK";
#else
    klauncher_header request_header;
    request_header.cmd = LAUNCHER_OK;
    request_header.arg_length = 0;
    kde_safe_write(kdeinitSocket, &request_header, sizeof(request_header));
#endif

Needless to say, it logs a "LAUNCHER_OK" message (on OSX), but fails to
send a reply to kdeinit5 and so kdeinit5 is blocked.  At least, that is certainly
what happens in kdeinit4 and klauncher4 on Apple OS X.

@David: If you would like a patch for this problem, I can work one out.  It
would preserve the usage of QProcess, but would also pass a reply back
on the socket, so that kdeinit5 can continue with its main() processing.

I am not sure yet whether the socket would also be needed for "telling
kinit what to do" --- or whether the code using QProcess handles those
kdeinit-style launches.  Ideas welcome.

Cheers, Ian W.

P.S. This problem might also affect kdeinit4/5 and friends on Windows.