Using QApplication::processEvents

[Jens Dagerbo]

On 5/2/06, Vladimir Prus <ghost at cs.msu.su> wrote:
>
> Hello!
>
> At the moment, the debugger code works like this:
>
>   - A command is sent to gdb
>   - When response arrives back, the slot that does the parsing is
>     called
>   - Callback specified when sending the command is called
>
> Using callbacks for all commands makes the overall control flow a little bit
> tricky, so I was thinking if the following approach is feasible:
>
>   GDBMI::ResultRecord* result = 0;
>
>   GDBMI::ResultRecord* send_command(QString& command)
>   {
>                 // send the command
>                 while(result == 0)
>                         QApplication::processEvents();
>          return result;
>   }
>
> The output of gdb will still be forwarded to a slot that will do the parsing
> and set the 'result' variable. With this arrangement, the rest of debugger
> code will be written is a simple imperative style, without any callbacks
> whatsoever.
>
> Are there any downsides to this approach? The one I see is that it's only
> possible to use this trick only once in entire program -- if there are two
> such places one will never get a chance to execute. But I'm not sure if
> that's the case with KDevelop? Any other drawbacks?
>
> - Volodya

Please don't.

QApplication::processEvents() is brilliant for creating bugs that are
really hard to understand and reproduce. Backtraces end up being
positively mystifying. After a call to processEvents() you no longer
know what state the UI is in or even if the project is still loaded..
We've had a fair few bugs in KDevelop already that were caused by
liberal use of processEvents().

There are still a few of them left and I have on my todo to remove a
few more of them.. please don't add more of them.

// jens