From kde-core-devel Mon Jan 24 04:20:37 2011 From: Dawit A Date: Mon, 24 Jan 2011 04:20:37 +0000 To: kde-core-devel Subject: Re: The hidden problem with using QProcess/KProcess in kdelibs... Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=129584290032029 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--0016e6509cc60089ad049a8fec44" --0016e6509cc60089ad049a8fec44 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 23, 2011 at 4:41 AM, Thiago Macieira 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. --0016e6509cc60089ad049a8fec44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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=3Dv= lc.git;a=3Dblob;f=3Dbin/vlc.c;h=3D70eeed0d2299e2f3cf0c
> 2f6819120f02d0703152;hb=3DHEAD
>
> 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<= br> > 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=3Dv= lc.git;a=3Dblob;f=3Dmodules/gui/qt4/qt4.cpp;h=3De27c4e
> d33161c1979db7fbe6f1d0f466db1c7e09;hb=3DHEAD

Well, there are two components here: the signal handler and the signa= l mask.

The line:
=C2=A0 =C2=A0 =C2=A0 =C2=A0signal(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<= br> handler is installed but never called.

That= is exactly what happens. Defaulting the SIGCHLD handler is really a non-is= sue since it is highly likely done way before QCoreApplication is called. H= owever, the call to the pthread_sigmask to block both SIGCHLD and SIGPIPE a= mongst others is what causes problem for QProcess.=C2=A0Having said that th= ough I have to take up an issue with the fact that there is not a single li= ne of commentary on this huge pitfall in the QProcess documentation ? Why ?= Is that because it is an internal implementation detail ?=C2=A0

Anyhow, after reading the response of one of the VLC de= velopers 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 somethi= ng like this was bound to happen. Oh well... I doubt there is anything we c= an 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.
--0016e6509cc60089ad049a8fec44--