QGIS Planet

First report

What do I have completed this week?

  • New implementation of the AlgorithmExecutor subclassing QObject.
  • Mechanism to deal with crashing Algorithms: when there is an exception during the algorithm execution, a signal is emitted in order to allow the main thread to make the other thread quit.
  • Use signal to connect the algorithm progress signal to the setPercentage slot in the ProgressBar

 

In the runAlgorithm method of the Processing class I changed the code associated with the runalg in order to support multithreading. Each time that an algorithm is running through the QGIS python console, a new thread and a new instance of the algorithm executor are created. The signals of the AlgorithmExecutor are connected to the thread signal in order to quit the thread and run the algorithm when the thread starts. While the algorithm is running, the main thread waits for the algorithm to finish and then proceed to show the output (first approach)

 

What am I going to achieve for the next week?

Create a non-blocking version of the processing in order to the interface not wait for the algorithm to finish.

Is there any blocking issue?

QGIS seems to crash randomly when starting the new thread and, when it doesn’t crash, the output of the algorithm is None, which may indicate that the algorithm is crashing in the new thread.

 

The complete report about the crashing can be found here.


Second report

What do I have completed this week?

  • A new implementation was designed to take into account several algorithms running. (using bounded signals)

  • Deep analysis of the processing in order to fit this new design into the current implementation of the Processing toolbox

  • Thread/Signal debugging

  • Fix the problem that makes QGIS crash when starting the new thread

 

What am I going to achieve for the next week?

Continue working on the new design of the multithreading support.

Is there any blocking issue?

There is no blocking issue for now.


Back to Top

Sustaining Members