On Friday, 4 de February de 2011 19:38:51 Oswald Buddenhagen wrote: > On Fri, Feb 04, 2011 at 06:28:10PM +0100, Thiago Macieira wrote: > > Em sexta-feira, 4 de fevereiro de 2011, às 18:17:13, Thiago Macieira escreveu: > > > I thought about that. My work on no-thread-until-pipes-close had > > > already documented this as a behaviour change. > > > > Think about it anyway: if the child process dies but the grandchild one > > doesn't, it will die when the current application exits. > > not if it doesn't actually care for its stdio, like most gui > applications. and as redirecting stdio is the default in qprocess, this > would happen rather often. > > > There is another drawback: the child process would be a Zombie until all > > its children died too. > > yes, and expected qt signals would not be delivered, so the parent would > livelock. > i've been through this ith naive implementations. trust me, it just > doesn't work.
Ok, fair enough. Threading-after-pipes-closed is not an option then.
That leaves back again at square one:
- one thread per subprocess
OR
- SIGCHLD handler
OR
- kernel developers give us some new syscalls like pidfd or waitpidv
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
pgpmA0f5CT6Dd.pgp
Description: This is a digitally signed message part.
