[Qgis-developer] Fwd: Threads in sextante

[Etienne Tourigny]

Hi Giuseppe!

On Sat, May 12, 2012 at 2:12 PM, Giuseppe Sucameli
<brush.tyler at gmail.com> wrote:
> Hi Etienne,
>
> On Sat, May 12, 2012 at 6:47 PM, Etienne Tourigny
> <etourigny.dev at gmail.com> wrote:
>> I always thought that gdaltools and ftools should be non-blocking
>> (unless I am mistaken, they are currently blocking the rest of the
>> app), especially if the operation takes a long time.
>
> GdalTools is non-blocking (uses QProcess to execute commands)
> and its dialogs are non-modal, so more operations can run
> concurrently and users can open all the gdaltools dialogs they need.

I stand corrected then - I guess I was confusing it with ftools, which
is blocking and does not spawn a process.
Any way ftools could be adapted to use the same approach as gdaltools?

>> This might have issues though with
>>
>> 1) progress report - can this be done by the executing thread?
>
> That's missing in GdalTools.
>
> Generally speaking, every time the execution thread emits the
> progress signal the main thread (GUI thread) updates the progressbar.
>
> Focused to GdalTools, it should get progress percent from the
> QProcess output but unfortunately a lot of other info goes to
> the process output.

If it were using the gdal api directly, it could get the progress and
report it though QProcess - but that's not possible as gdaltools calls
the command-line apps directly.
There was some talk on the gdal-dev mailing list about putting the
gdal utilities in the api, but this probably won't happen really soon.

However - this hack might work - when the characteristic
'0...10...20...30...40...50...60...70...80...90...100 - done.' output
is detected (say after '0...10') then the output would be interpreted
as progress report, which could be used to update the gui every 10% -
until 100 is read. I have never seen output mixed with progress report
in gdal utilities, although I may be wrong.

An example with gdalwarp:

$ gdalwarp -s_srs EPSG:4326 -ts 6000 6000 -of GTiff
/data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif
/data/tmp/tmp1.tif
Creating output file that is 6000P x 6000L.
Processing input file
/data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif.
Using internal nodata values (eg. 0) for image
/data/research/work/modis/2000-2010_jun-may/MCD45.ba_qa.cerrado.2000-2001.wgs84.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.
$

>
>> 2) what happens when the operation finishes
>
> The execution thread emits a signal and the main thread
> display a message according to the signal (error, finished).
>
>> Ideally, there should be a way to cancel an operation, if it takes too
>> long (e.g. escape key when the operation window has focus)
>
> Stopping/killing the execution thread should be enough.
> GdalTools asks for confirmation and then does it.

This has to be done manually, externally to qgis though. Would it be
possible to have a "Cancel" button in the dialogs that would respond
to user input, or respond to the Escape key when pressed?

>
>> Also, this could enable several similar operations to be done in
>> parallel - as long as they are not working on the same output files.
>
> That must be taken care from the framework: an operation that needs
> as input outputs generated by other operations must be started only
> after the required outputs are ready...
> ... and the key is to use signals, again.

Am I wrong to think that currently, 2 gdaltools operations could run
concurrently with the same output file, with all associated problems?
You are talking about implementing this sort of thread-safe checks
into the sextante framework, right?

thanks
Etienne

>
> Regards.
>
>> Etienne
>>
>> On Fri, May 11, 2012 at 3:25 AM, Paolo Cavallini <cavallini at faunalia.it> wrote:
>>> Il 10/05/2012 23:15, Martin Dobias ha scritto:
>>>
>>>> What should be the benefit of multithreading here? To run algorithms
>>>> outside from main thread so that GUI does not get blocked?
>>>
>>> IMHO this is the main reason; I think the way GDALTools work is fine for the user.
>>> All the best.
>>>
>>> --
>>> Paolo Cavallini - Faunalia
>>> www.faunalia.eu
>>> Full contact details at www.faunalia.eu/pc
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Giuseppe Sucameli