From kde-core-devel Sat Jan 22 22:16:10 2011 From: Dawit A Date: Sat, 22 Jan 2011 22:16:10 +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=129573479016802 On Sat, Jan 22, 2011 at 3:55 PM, Thiago Macieira wrote: > On Saturday, 22 de January de 2011 14:25:07 Dawit A wrote: >> Anyhow, this problem is not specific to VLC and can happen to any Qt >> application that blocks the SIGCHLD signals from reaching any of the >> threads. As such I think some action needs to be taken to address this >> issue. We can workaround this issue by unseting and setting the signal >> masks in the aforementioned function, but there are many other places >> in kdelibs where QProcess is used so perhaps a better resolution is >> needed for this ? Perhaps it is QProcess that should be taking care of >> this itself ? > > I agree with you. QProcess relies on SIGCHLD being delivered to its signal > handler. Unlike VLC, we don't try to mask it to one thread only. Instead, the > signal handler function is written so that it can be run on any thread, and it > signals an auxiliary thread (the QProcessManager thread) to do the non-async- > safe operations. Which is a much much saner thing to do than what the VLC folks chose to do in their code. > So for QProcess to work, it requires that people don't disrupt the above. > > Setting signal masks is fine as long as you don't block it -- the signal > handler will still be invoked in one thread. If you override with a different > handler, then at least ensure Qt's is run. They simply seem to block it and not be concerned with it at all. At least that is what it looks like to me, not only from the code but also the comments written in the code. > If the code you pasted from VLC is run after QCoreApplication's constructor, > the signal(SIGCHLD, SIG_DFL); call removes QProcessManager support. The above snippet of code is something I clipped from http://git.videolan.org/?p=vlc.git;a=blob;f=bin/vlc.c;h=70eeed0d2299e2f3cf0c2f6819120f02d0703152;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=e27c4ed33161c1979db7fbe6f1d0f466db1c7e09;hb=HEAD