[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Review Request 126161: OS X housekeeping
From:       David Faure <faure () kde ! org>
Date:       2015-11-30 8:01:25
Message-ID: 8196488.3Iv8L1UKSc () asterix
[Download RAW message or body]

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, faure@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


[prev in list] [next in list] [prev in thread] [next in thread]