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