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

List:       kde-core-devel
Subject:    Re: The hidden problem with using QProcess/KProcess in kdelibs...
From:       Thiago Macieira <thiago () kde ! org>
Date:       2011-01-23 9:34:35
Message-ID: 20110123093447.0156273F9 () nargothrond ! macieira ! info
[Download RAW message or body]


On Saturday, 22 de January de 2011 21:50:46 Michael Pyne wrote:
> On Saturday, January 22, 2011 16:53:29 Thiago Macieira wrote:
> > On Saturday, 22 de January de 2011 22:08:25 Christoph Bartoschek wrote:
> > > Am Samstag 22 Januar 2011 schrieb Thiago Macieira:
> > > > However, what I really want is that kernel developers give me a
> > > > modern way of finding out a process has exited.
> > > 
> > > Hi, I do not know whether it works as desired, but did you look at
> > > signalfd(2)?
> > 
> > Doesn't solve the problem. You still need to block the signals in all
> > threads signalfd can receive it.
> > 
> > It needs to be done without signals.
> 
> Perhaps I'm missing something obvious, but what is missing from waitpid(2),
> or the more recent waitid(2)? Both of those allow you to wait for specific
> processes. It would have to be done in an alternate thread to avoid
> blocking but you've already mentioned using a separate thread to support
> the current SIGCHLD signal handler.

I'd have to start one thread per subprocess I wanted to watch.

I want something I can put on select(2) or poll(2).

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

["signature.asc" (application/pgp-signature)]

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