[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-mac
Subject: [KDE/Mac] Potential blocker in kdeinit5 and klauncher5 on OS X
From: Ian Wadham <iandw.au () gmail ! com>
Date: 2015-02-04 4:31:52
Message-ID: 4AA16D7D-45D7-4128-9117-D53B3462C07E () gmail ! com
[Download RAW message or body]
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@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic