QProcess::startDetached and bash stdout capture

[David Faure]

On samedi 25 mars 2017 16:50:37 CET Thiago Macieira wrote:
> One problem is because the launched process inherits the pipes to stdout and
> stderr

Really, even with startDetached? I assumed that was more "detached" than that 
;)

> but the shell sees the process group it launched exiting.

I never understood much about "process group". Is it the issue here? Is the 
helper considered part of the same process group as kdialog?

> It will probably close the pipe. Normally, this process would exit soon with
> SIGPIPE, but since a lot of code relating to sockets and pipes turns
> SIGPIPE off, it's possible that the detached process never receives SIGPIPE
> and simply remains forever.

I'm confused as to which one you call the "detached process" here,
kdialog or the helper.

Are you saying what I need is a call to sigaction to re-enable exiting on 
SIGPIPE, in kdialog, just before returning from main()?

Could it be related to SIGCHLD, rather? I know QProcess[Manager] plays with 
that, and it sounds like what the shell is waiting for from kdialog. But 
surely inhibiting the -receiving- of SIGCHLD in kdialog shouldn't break the 
parent shell receiving SIGCHLD when kdialog terminates?

> > I tried close(1) like the kde4 kdialog was doing (due to forking, though),
> > no change.
> 
> There's another problem: you have a race condition between the parent
> (kdialog) exiting and the grandchild (helper) writing its information before
> closing stdout.

No no, kdialog is the one writing to stdout. It's just writing out the dbus 
service name that it knows the helper will use.
It's much simpler that way, it avoids all the issues you mention.

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