Hi,
in making some of the python modules multithreaded, it would be
useful to have a version of grass.mapcalc() which didn't wait
until it was done, and returned the Popen object instead.
e.g. to process three r,g,b bands in parallel.
I just added an experimental grass.mapcalc_start() fn to trun
Hamish wrote:
> in making some of the python modules multithreaded, it would
> be useful to have a version of grass.mapcalc() which didn't
> wait until it was done, and returned the Popen object instead.
>
> e.g. to process three r,g,b bands in parallel.
>
> I just added an experimental grass.map
Hamish wrote:
> in making some of the python modules multithreaded, it would be
> useful to have a version of grass.mapcalc() which didn't wait
> until it was done, and returned the Popen object instead.
>
> e.g. to process three r,g,b bands in parallel.
>
> I just added an experimental grass.m
> Hamish wrote:
> > I just added an experimental grass.mapcalc_start() fn
> to trunk/lib/python/raster.py, any comments or better ideas
> how to do it?
Glynn:
> The function looks okay, although using Python threads may
> be a better approach in general.
why so? for mapcalc_start() or start_comm
Hamish wrote:
> > The function looks okay, although using Python threads may
> > be a better approach in general.
>
> why so? for mapcalc_start() or start_command()?
For running multiple r.mapcalc processes concurrently. Eventually,
there may be other long-running functions like mapcalc(), so
