The hidden problem with using QProcess/KProcess in kdelibs...

[Dawit A]

On Sun, Jan 23, 2011 at 4:41 AM, Thiago Macieira <thiago at kde.org> wrote:

> On Saturday, 22 de January de 2011 17:16:10 Dawit A wrote:
> > The above snippet of code is something I clipped from
> >
> http://git.videolan.org/?p=vlc.git;a=blob;f=bin/vlc.c;h=70eeed0d2299e2f3cf0c
> > 2f6819120f02d0703152;hb=HEAD
> >
> > One cannot easily tell where QCoreApplication's ctor is getting
> > called, but I suspect it is sometime after the call to libvlc_new(...)
> > at line #201 and hence after all these signal blocking has occurred ??
> > Since I was really not sure and did not want to waste to much time
> > mucking around in a rather large and complex code base, I actually
> > created a small test case to simulate the condition. I can clean that
> > up and post it here if you want.
> >
> > Oh and the code that instantiates QCoreApplication seems to be located
> > around line #533 in:
> >
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/gui/qt4/qt4.cpp;h=e27c4e
> > d33161c1979db7fbe6f1d0f466db1c7e09;hb=HEAD
>
> Well, there are two components here: the signal handler and the signal
> mask.
>
> The line:
>        signal(SIGCHLD, SIG_DFL);
>
> unsets the handler. It's bad if it's called after QCoreApplication. If it's
> called before, it's harmless.
>
> However, if all signals are blocked (and they seem to be), then the signal
> handler is installed but never called.


That is exactly what happens. Defaulting the SIGCHLD handler is really a
non-issue since it is highly likely done way before QCoreApplication is
called. However, the call to the pthread_sigmask to block both SIGCHLD and
SIGPIPE amongst others is what causes problem for QProcess. Having said that
though I have to take up an issue with the fact that there is not a single
line of commentary on this huge pitfall in the QProcess documentation ? Why
? Is that because it is an internal implementation detail ?

Anyhow, after reading the response of one of the VLC developers in bug
report I listed in the original email, I am convinced that the reliance on
signals, which can so easily get cleared or worse blocked, in a library
class seems a really bad idea. It is almost inevitable something like this
was bound to happen. Oh well... I doubt there is anything we can do about
this in kdelibs short of finding a way to avoid the calling the function
that relies on QProcess, which is futile because there are a lot of other
places in kdelibs that depend on it too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110123/d1529658/attachment.htm>