[Qgis-developer] Fwd: Threads in sextante
etourigny.dev at gmail.com
Sat May 12 11:56:52 PDT 2012
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
Creating output file that is 6000P x 6000L.
Processing input file
Using internal nodata values (eg. 0) for image
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?
>> 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
>>> Full contact details at www.faunalia.eu/pc
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
> Giuseppe Sucameli
More information about the Qgis-developer