<p dir="ltr">Thanks for the responses, I'm looking forward to trying out your suggestion, Pietro. Pygrass looks interesting, but I'm a little confused about its relationship with grass.script.</p>
<p dir="ltr">One of the reasons I'm trying to use multiprocessing is because it side steps the GIL issue by not using threads, according to the documentation (<a href="http://docs.python.org/2/library/multiprocessing.html">http://docs.python.org/2/library/multiprocessing.html</a>). I didn't think the grass.start_command() would use all the available CPUs. I've used multiprocessing with the gdal python api and it made use of all my cpu cores.</p>

<p dir="ltr">Eric</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eric wrote:<br>
<br>
>>  If I run the script without multiprocessing enabled the script<br>
>>  executes properly; If I run it with multiprocessing enabled,<br>
<br>
just some 2c, I don't remember the exact details, but when we were<br>
working on the multi-processing functions in core.py we went with<br>
the subprocess python library instead of the multiprocess one as<br>
it seemed to be a better fit for the collection of modular programs<br>
used by GRASS in the usual way. Since pygrass is a different way of<br>
thinking about the structure, maybe the lower-level multiprocess is<br>
more appropriate to use with that (or not), I'm not sure.<br>
<br>
<br>
>> Can the use_temp_region() function  be used as it is below to execute<br>
>> multiple mapcalc jobs in parallel that have different extents?<br>
>> Once I have this working I'd like to make  a more generic tool a-la<br>
>> the i.landsat/toar tools.<br>
<br>
see also the mapcalc_start() python command in lib/python/script/raster.py,<br>
and start_command() in core.py, and how they are used by e.g. <a href="http://i.landsat.rgb.py" target="_blank">i.landsat.rgb.py</a>,<br>
<a href="http://i.pansharpen.py" target="_blank">i.pansharpen.py</a>, <a href="http://i.oif.py" target="_blank">i.oif.py</a>, and <a href="http://r3.in.xyz.py" target="_blank">r3.in.xyz.py</a>.<br>
<br>
(that uses grass.script, the best way to do it with pygrass may be different)<br>
<br>
<br>
Pietro:<br>
> I don't think that the function use_temp_region, can solve your problem,<br>
> If you look at the code [0], the function set the environmental variable,<br>
> therefore in a multiprocessing environment you have several process that<br>
> set the same variable at the same time...<br>
<br>
the environment variables are isolated within a process as soon as the new OS<br>
process is launched, it is impossible for a child process to share or export<br>
environment variables back to its parent or among siblings. A process inherits<br>
the environment as it was when it was launched, and any changes within that proc's<br>
environment which happen during run-time evaporate with it when the process is<br>
reaped. As long as WIND_OVERRIDE (ie use_temp_region()) is always used by modules<br>
which want to change the region, and only g.region from the top-level is allowed<br>
to change the real WIND file, then all should be ok.<br>
<br>
since python doesn't really allow true multithreading (it is stuck on one<br>
core thanks to GIL) it just spawns multiple processes to emulate it, and so<br>
as long as there are multiple processes there will be multiple environments<br>
for each. (again, I'm not a pygrass expert so please correct if my assumptions<br>
are bad)<br>
<br>
<br>
> myenv = os.environ.copy()<br>
> # now change the variables in the dictionary<br>
> myenv['GISRC'] = 'mygisrc'  # etc.<br>
> run_command('r.something', bla, bla, env=myenv)<br>
<br>
I would be very surprised if changing GISRC was the correct approach<br>
for anything other than working on a large cluster with a job manager<br>
and e.g. NFS issues to deal with.<br>
<br>
<br>
regards,<br>
Hamish<br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</div>