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

List:       kde-mac
Subject:    Re: [KDE/Mac] Review Request 126161: OS X housekeeping
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-11-26 9:27:31
Message-ID: 32216803.yvARFJafgF () patux
[Download RAW message or body]

On Thursday November 26 2015 08:54:25 David Faure 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.

You've got a point, but I don't see how `ps -axxlw | fgrep <command>` can miss \
something unless it has an unexpected name. Which is possible (I don't think I search \
for kwrapper instances) but would still mean that `killall` won't work.

I should check the exact parameters given to the execve() call.

> > 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 ?

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. I presume we'd have to dig deep \
into some very lowlevel OS X code to know what's going on. BTW, I may be wrong, but \
from what I understand the crash is provoked intentionally, i.e. it's a sort of \
abort.

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

Maybe the above helps a wee bit?

> 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?

Ah. Indeed, we have NOT tried the simple fork+dlopen approach, for some reason (your \
patch skips the `l.load()` step). However, supposing that it's in fact the dlopen in \
the child process that's off-limits, relaying it to an exec'ed helper still seems to \
produce more comparable behaviour.

There's something I don't really understand though: the exact same question you asked \
above. What's the difference between starting kwrite directly on the commandline (or \
through execve()), and dlopen'ing it? Why does the code go through that on Linux? \
Whatever that difference is, it's probably the reason why the approach fails on OS X.

Final thing: did you see the question about the socket file klauncher leaves behind? \
Is it possible to let it be removed when klauncher exits?

R.
_______________________________________________
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]