On Thursday 26 November 2015 10:27:31 René J.V. Bertin wrote:
> Yes, the *helper* does that, from within the newly exec'ed process. It's
> weird, but apparently the exact "forbidden" thing is "fork - call/load
> non-POSIX APIs - exec" while "fork - exec - call/load non-POSIX APIs" works.
That confirms my point. fork+dlopen is forbidden, while fork+exec is OK --
whether that means exec kwrite or exec the helper proxy.
> >I don't understand the difference between "execute kwrite" and "execute a
> >proxy executable that dlopens kwrite".
>
> Maybe the above helps a wee bit?
No it doesn't. It's fork+exec in both cases, both should work.
> Ah. Indeed, we have NOT tried the simple fork+dlopen approach, for some
> reason (your patch skips the `l.load()` step).
Don't, it's the thing that kdeinit was doing initially (since it's what it does
on linux, whenever possible, i.e. when a .so is found) and which created
problems on OSX.
> What's the difference between starting kwrite directly on the commandline (or
> through execve()), and dlopen'ing it?
On Linux: it skips the cost of relocations which happen when starting a new
binary. kdeinit already links to the major shared
libraries, so it's faster to fork and dlopen.
On OSX: it falls into the forbidden case.
> ... if kdeinit5 and/or kwrapper5 are supposed to be able to launch() shared
> libraries containing kdeinitmain or kdemain.
You seem to be missing one point: every application which provides a .so
("kdeinit module") *also* provides a binary, always.
The kdeinit module is only an optimization. Every app needs to have a standard
executable, for other means of starting it.
The entry point into kdeinit is "start kwrite please". kdeinit decides whether
to do that using the kdeinit module (.so) or the executable.
So it's perfectly fine to only support executables. That's also what happens on
Windows.
I never realized you could pass a shared lib to kwrapper5, that is definitely
not the intended usage, and I can tell you, nobody does this ;)
> That appears to be the case indeed: `kwrapper5 /path/to/kwrite` is faster
> than `kwrapper5 /path/to/libkdeinit4_kwrite.dylib`.
> A bit surprising, because someone still has to open that dylib even when
> exec'ing `kwrite` ... am I missing something?
Yes but I bet it means some symbol lookups happen at runtime rather than at
link time. I'm not enough of a lowlevel
mac toolchain expert to give a fully satisfying explanation, but I'm not very
surprised.
--
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
