Review Request 126161: OS X housekeeping

[David Faure]

On Wednesday 25 November 2015 16:45:25 René J.V. Bertin wrote:
> 
> No, with "my" fix, applications started through kwrapper appear as individual entries in `ps` listings, with your fix only the `kwrapper5 /path/to/command` entry shows up.

I don't see how that's possible.
If kdeinit forks, surely you see a separate process for that.
kwrapper merely sends a message to kdeinit, asking it to execute the application, it has no code to execute the app itself.
Are you sure you're not missing an entry in the ps list?

> Also, if your fix does a "real fork + exec", how come it doesn't run afoul of the limitations imposed on that on OS X?

I don't understand this reasoning. Your patch does fork+exec too, except that it executes the helper executable
(which then loads the kdeinit module) instead of executing the kwrite executable. I don't see how that makes any difference to OSX ?

> Only because it doesn't actually load `l` (the result of QLibrary(libpath)), meaning the crash will return the day kdeinit5 itself does something off-limits? The helper from my fix is probably much less likely to develop such symptoms. And even if it does (through Qt) it would be much easier to cure (make it not use Qt at all but only POSIX APIs).

I don't understand the difference between "execute kwrite" and "execute a proxy executable that dlopens kwrite".

> For the rest, using a helper does seem to give a better "emulation" of what `kdeinit5` does on Linux, no?

Not at all, kdeinit on linux does fork+dlopen, no exec.
But my point is exactly that: if fork+dlopen is a problem on OSX, then don't do it, do fork+exec. That's what you do,
but then why exec something that will dlopen, instead of exec the real thing?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5