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

[Dawit A]

On Sat, Jan 22, 2011 at 5:16 PM, Dawit A <adawit at kde.org> wrote:
> 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.

Here is the sample program I created to simulate this issue.

There is one more thing that happens... In my sample program, the
version information is correctly read once the timeout is reached.
However, that does not happen when using VLC, which means they are
doing even other more crazier things...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_qprocess.cpp
Type: text/x-c++src
Size: 3512 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110122/649a73f8/attachment.cpp>