[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: Dawit A <adawit () kde ! org>
Date: 2011-01-24 4:20:37
Message-ID: AANLkTi=1yPPik8a1YC5UcFdrbtzxbpAFBXApGvQ4EwOU () mail ! gmail ! com
[Download RAW message or body]
On Sun, Jan 23, 2011 at 4:41 AM, Thiago Macieira <thiago@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.
[Attachment #3 (text/html)]
<div class="gmail_quote">On Sun, Jan 23, 2011 at 4:41 AM, Thiago Macieira <span \
dir="ltr"><<a href="mailto:thiago@kde.org">thiago@kde.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">On Saturday, 22 de January de 2011 \
17:16:10 Dawit A wrote:<br> > The above snippet of code is something I clipped \
from<br> > <a href="http://git.videolan.org/?p=vlc.git;a=blob;f=bin/vlc.c;h=70eeed0d2299e2f3cf0c" \
target="_blank">http://git.videolan.org/?p=vlc.git;a=blob;f=bin/vlc.c;h=70eeed0d2299e2f3cf0c</a><br>
> 2f6819120f02d0703152;hb=HEAD<br>
><br>
> One cannot easily tell where QCoreApplication's ctor is getting<br>
> called, but I suspect it is sometime after the call to libvlc_new(...)<br>
> at line #201 and hence after all these signal blocking has occurred ??<br>
> Since I was really not sure and did not want to waste to much time<br>
> mucking around in a rather large and complex code base, I actually<br>
> created a small test case to simulate the condition. I can clean that<br>
> up and post it here if you want.<br>
><br>
> Oh and the code that instantiates QCoreApplication seems to be located<br>
> around line #533 in:<br>
> <a href="http://git.videolan.org/?p=vlc.git;a=blob;f=modules/gui/qt4/qt4.cpp;h=e27c4e" \
target="_blank">http://git.videolan.org/?p=vlc.git;a=blob;f=modules/gui/qt4/qt4.cpp;h=e27c4e</a><br>
> d33161c1979db7fbe6f1d0f466db1c7e09;hb=HEAD<br>
<br>
</div>Well, there are two components here: the signal handler and the signal \
mask.<br> <br>
The line:<br>
signal(SIGCHLD, SIG_DFL);<br>
<br>
unsets the handler. It's bad if it's called after QCoreApplication. If \
it's<br> called before, it's harmless.<br>
<br>
However, if all signals are blocked (and they seem to be), then the signal<br>
handler is installed but never called.</blockquote><div><br></div><div>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 ? </div> <div><br></div><div>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.</div> </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic