[Qgis-developer] Fwd: Threads in sextante

[Martin Dobias]

Hi Camilo

On Tue, May 29, 2012 at 11:18 AM, Camilo Polymeris <cpolymeris at gmail.com> wrote:
> As said, I went with QThreads for this paticular case, because:
> a) QProcess, I think, belongs in another level (the calling the
> auxiliary programs layer) and I am not sure it applies to potential
> backends using libraries.
> b) QtConcurrent seems not to have pyqt bindings
>
> I might be wrong on any (or both) of these points. Please comment.

a) the approach with separate processes would be possible too, but
IMHO not really needed. The main advantage is complete separation of
execution, so if your child process fails it does not bring parent
(QGIS) with it (in contrast to threads). The disadvantages lie in more
complex inter-process communication and inability to directly use
running QGIS environment. Threads fit better your scenario - some
algorithms (e.g. GRASS) are run as separate processes anyway.

(Btw. some internet browsers (notably Chrome) nowadays use processes
(instead of just threads) for each opened tab - AFAIK the main reason
for that is security and stability - Flash plugin will break just the
tab where it crashed.)

b) there are no PyQt bindings for QtConcurrent and there is not much
sense to port it to Python: it is intended as a general high-level
interface for threading - python has its own APIs (threading,
multiprocessing modules).


Martin