Review Request: Workaround for the hang (freeze) when opening VLC's file dialog under KDE...

Dawit A adawit at kde.org
Fri Feb 4 21:35:32 GMT 2011


On Fri, Feb 4, 2011 at 3:32 PM, Thiago Macieira <thiago at kde.org> wrote:
> On Friday, 4 de February de 2011 14:06:58 Dawit A wrote:
>> BTW, there is one side issue I noticed in QProcess through this whole
>> process. Why does QProcess not exit immediately if I invoke kill or
>> terminate or even when it just timed out from waiting for the child
>> process ? IOW, why wait some more for the child process to exit under
>> those circumstances ? That is what unnecessarily prolongs or even
>> doubles the blocking period.
>
> kill() or terminate() just send the signals. There's no guarantee that the
> process will exit immediately, so why should QProcess notify you of that
> immediately? This is especially true for SIGTERM, since that one can be caught
> and handled.

Let us take out terminate from the equation. It is my mistake I
included it here because its documentation states that "The process
may not exit as a result of calling this function". However, I really
do not understand why what you stated matters for the kill() and timed
out scenarios...

QProcess process;
process.start(...);

If the next command I issue is

process.waitForFinished();

I expect it to wait 30 secs since that is what the default value for
the timeout parameter states. There is no way I would expect it to
block for another 30 sec when the variable goes out of scope because
of its own internal implementation issues. It is doing waitForFinished
on a child process it created itself. Nothing to do with the API
caller.

The case of the kill is even more baffling to me because its
documentation clearly says "Kills the current process, causing it to
exit immediately". So If I kill is invoked as such

process.kill();

what should a reasonable expectation be ? To me the process gets
killed immediately. Done, poof, gone. Instead that too blocks for the
default amount of period if there are internally forked processes that
are still running when the dtor is encountered yet again.

Oh well, perhaps I am simply expecting QProcess to work the way it
makes sense to me and am simply missing a larger point which I fail to
recognize.




More information about the kde-core-devel mailing list