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

[Jeremy Whiting]

Ian,

I would be very interested in this fix. You say you already did the fix on
kdelibs? If you can point me at the commit I can take a look at doing the
same on frameworks if you want. Since I can build and test while doing it
here.

thanks,
Jeremy

On Tue, Feb 3, 2015 at 9:31 PM, Ian Wadham <iandw.au at gmail.com> wrote:

> 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.
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150204/3e2ec045/attachment.html>