[QGIS-Developer] [GRASS-dev] Running grass algorithms in threads

[Nyall Dawson]

> I strongly suspect that grass algorithms cannot be run in parallel.
> This is why they cannot run in the background in QGIS like the native/GDAL algorithms can. But I'd love for confirmation about this and whether there's any way to make GRASS multi-thread safe.

Just to clarify here -- I was referring to the GRASS provider in QGIS,
not GRASS itself, when I stated that the algorithms could not be run
in parallel. I phrased that badly!

> On Wed, Aug 15, 2018 at 11:54 AM Rudi von Staden <rudivs at gmail.com> wrote:
> >
> > Thanks all for your thoughts on this. I suspect the problem may be race conditions being set up between https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/Grass7Utils.py and https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/Grass7Algorithm.py. It attempts to use an existing session and shared mapset which could be problematic from the sounds of things. It might be an idea to add an optional parameter to grass algorithms to not use shared mapsets and create a new mapset for each process?
>
> It just came in yesterday :)
>
> See
> https://lists.osgeo.org/pipermail/grass-user/2018-August/078936.html
> [GRASS-user] New CLI option --tmp-location in 7.5 to enhance --exec
>
> Perhaps this approach will solve the issues?

I don't think this is the issue in QGIS.

Indeed the GRASS Processing provider in QGIS currently re-uses a
single temporary mapset for an entire QGIS session. This means all
GRASS algorithms executed use the same mapset, which as stated earlier
in this thread can cause issues.

We could potentially switch to a single temporary mapset for each
individual algorithm executed, but I'd need to look into the
ramifications of that change in depth, as it could potentially cause
performance regressions for users who execute GRASS algorithms
sequentially.

Nyall



>
> Best
> Markus