Hi,
my name is Luis Gonçalves Seco.
I whould like to know, if it is possible to have more then one session of GRASS running at the same time?
Thanks
Kind regards,
Luis Gonçalves Seco
Electronic Systems Department
University of Coruña
Spain
Luis Goncalves Seco wrote:
I whould like to know, if it is possible to have more then
one session of GRASS running at the same time?
You would need to remove the locking code from $GISBASE/etc/Init.sh:
# Check for concurrent use
"$ETC/lock" "$lockfile" $$
case $? in
...
If you remove this, you would need to ensure that:
a) you don't run multiple sessions using the same mapset, and
b) that you don't use a monitor name (x0, x1, PNG etc) multiple times;
monitor names are per-user, not per-session or per-mapset.
--
Glynn Clements <glynn.clements@virgin.net>
I have been working this way on a Beowulf cluster with a shared filesystem. The results were excellent: submitting many GRASS
commands in parallel from different mapsets in the same database sped up working time considerably. IMO this is one of the great advantages of OS source systems like GRASS and Beowulf compared to commercial systems.
I wonder if the locking mechanism could be permanently adapted this way. As far as I can see, GRASS only writes to the current mapset, so only there a lock has to be provided. If lockfiles were put and read in the current mapset, concurrent use of GRASS would be possible in most cases. Would this be somethig for a feature request?
Jan
Glynn Clements wrote:
Luis Goncalves Seco wrote:
I whould like to know, if it is possible to have more then one session of GRASS running at the same time?
You would need to remove the locking code from $GISBASE/etc/Init.sh:
# Check for concurrent use
"$ETC/lock" "$lockfile" $$
case $? in
...If you remove this, you would need to ensure that:
a) you don't run multiple sessions using the same mapset, and
b) that you don't use a monitor name (x0, x1, PNG etc) multiple times;
monitor names are per-user, not per-session or per-mapset.