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

[Dawit A]

On Sat, Jan 22, 2011 at 3:55 PM, Thiago Macieira <thiago at kde.org> 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