On Wednesday, 27 February 2019 12:22:05 PST Thiago Macieira wrote:
> Good point: so long as the parent process is still running, it MUST
> waitpid() on the child processes. So even if we make QProcess front-end
> abandon the child, the backend in forkfd must still know about it.
>
> When the paren
On Wednesday, 27 February 2019 11:35:21 PST Oswald Buddenhagen wrote:
> it's unreasonable to risk tearing down "detached" children on process
> exit; that would be a totally fake api. also, you can't just pretend
> that the children aren't yours, because you need to collect the zombies,
> so at bes
On Wed, Feb 27, 2019 at 08:20:43PM +0300, Konstantin Tokarev wrote:
> 27.02.2019, 19:00, "Thiago Macieira" :
> > On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote:
> >> Is it technically possible to start() and then detach()?
> >
> > No, because the way to start changes. The detached mode
27.02.2019, 19:00, "Thiago Macieira" :
> On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote:
>> Is it technically possible to start() and then detach()?
>
> No, because the way to start changes. The detached mode requires a double fork
> and the actual detaching from the TTYs.
>
> You can
On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
No, because the way to start changes. The detached mode requires a double fork
and the actual detaching from the TTYs.
You can orphan / forget about the child, but it won't be de
On Wed, Feb 27, 2019 at 07:59:12AM +0100, J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
>
it wouldn't work particularly well on unix.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listi
On Wed, Feb 27, 2019 at 12:24 PM Joerg Bornemann
wrote:
> I'm not sure, I'm following. The non-static startDetached supports
> everything the static startDetached allowed. No functionality is going
> away, even if the static method is completely removed.
>
Right, sorry. I didn't realize that a n
On 27/02/2019 07:59, J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
>
> QProcess process;
> process.setFoo(...);
> process.start(...);
> process.waitForBar();
> process.read(...);
> process.detach();
In principle, yes. But what happens when detaching a process that's
On 27/02/2019 11:03, Konstantin Shegunov wrote:
> ]...] I use the static `QProcess::startDetached`
> to start the daemon and detach from the controlling terminal (on Linux).
> I need *AN* API to do this, otherwise I'd have to (re)implement
> double-forking myself. If there are changes I'm going
On Wed, Feb 27, 2019 at 9:00 AM J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
> [...]
>
This is quite important for me. I have a module that implements a
daemon/service[1] (due to QtService being old and not integrating with
windows' service manager) and I use the s
On Wed, Feb 27, 2019, 07:35 Simon Hausmann wrote:
> I’m in favor of deprecating the static overloads. Compilers give nice
> deprecating warnings these days and the non-deprecated interface remains
> nice and clear.
>
> Just my two cents,
> Simon
>
> > On 27. Feb 2019, at 02:56, Thiago Macieira
>
I’m in favor of deprecating the static overloads. Compilers give nice
deprecating warnings these days and the non-deprecated interface remains nice
and clear.
Just my two cents,
Simon
> On 27. Feb 2019, at 02:56, Thiago Macieira wrote:
>
> With a lot of thanks to Jörg's effort, since Qt 5.9 w
With a lot of thanks to Jörg's effort, since Qt 5.9 we have a non-static
startDetached() method, which do honour the environment set with
setProcessEnvironment, the current working dir with setWorkingDirectory, etc.
I think it's a far superior option. By far, it avoids the mistake that led to
Q
13 matches
Mail list logo
