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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
