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

List:       kde-core-devel
Subject:    Re: KProcess eats SIGCHLD, so pclose() fails
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-11-28 23:54:25
[Download RAW message or body]

On Wednesday 28 November 2001 09:32 am, David Faure wrote:
> KProcessController, instantiated by KProcess, seems to grab all SIGCHLD
> events, even the ones that have nothing to do with KProcess.

Unix signals were not designed with modular design in mind :-(

> For instance I'm using popen() and pclose(), and the pclose() returns -1
> with errno set to "no child process", due to this.
>
> See the attached testcase, to be compiled with
> g++ -I$QTDIR/include -L$QTDIR/lib popenkde.cpp -o popenkde -lqt -lkdecore
> And run "./popenkde blah" (blah being the executable that doesn't exist ;)
> Before the KProcess creation, the test works fine, after it it doesn't.
>
> Is there anything that can be done about this ? (I'm no kprocess / unix
> signal expert). Or do we really require all code run in a KDE application,
> to use KProcess instead of popen/pclose ? This makes it hard to use
> 3rd-party libraries, in e.g. a KPart, since konqueror uses KProcess for
> other things.

You will need to use KProcess. Using system() or other functions which require 
or change the SIGCHLD signal in KDE applications leads to errors. (We had a 
very weird error in Konsole in KDE 2.2.1 for example, where a system()-call 
did eat a SIGCHLD of the shell so that we failed to detect that the shell 
closed.)

Like I said, unix signals are not designed with modular design in mind, 
KProcess corrects that problem but that only works as long as everyone uses 
it.

It's strange that pclose doesn't work at all btw, system() temporarily 
disables the SIGCHLD (that solves nothing because now KProcess will miss 
them, so it only moves the problem) so that it will be able to catch the 
process exit correctly. One would expect that pclose would do the same. 

Cheers,
Waldo

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