multiple instances of G_[get][set]env

[Conn Copas]

Steve Dzurenko writes:
> 
> 
> Is there a problem with mulitple instances of the functions
> G__getenv() and G_setenv() running at the same time?  I thought
> I read somewhere that this is a problem, like multiple applications
> trying to connect to the same GRASS monitor at the same time.
> 
> I have two applications that need to run simultaneously.  They
> both make a fair amount of calls to G__getenv() and G_setenv().
> Every now and then, things blow up and one application or the
> other fails.  I believe I have narrowed the problem down to the
> calls to G__getenv() and G_setenv().  
> 
> Does anyone know what might be happening?
> 
As the names suggest, get/setenv either read or set environment variables.
These are normally process-specific, so peer processes should not be able to
set the environment of each other, and thus cause interference. However, this
can occur indirectly. In particular, the 'currently selected' monitor is
written to the $GISRC file, and thence read from the environment before
processes attempt many display operations. Another potential source of 
interference is that processes can write the current region information to a
shared file, although I can't remember whether this is ever exported into the
environment. The word 'application' in the context of Grass is a touch 
misleading, as every user command is a self-contained, asynchronous process, 
like Unix. If users 'enter' Grass through the front-end, then (a) one user
cannot run multiple sessions, and (b) different-user processes cannot share
the one monitor. I presume you have bypassed the front-end in order to run 
multiple applications under the same user name, so this is a non-issue. Two 
processes can write to the one monitor, but not simultaneously (one process
will be unable to connect to the monitor process). 

Offhand, I can't think of any reason why getting or setting the _environment_
should fail, but note that G_setenv also writes to the $GISRC file, unlike
G__setenv. Unix should take care of any deadlock situation between multiple
processes there, but it could mean that inconsistencies arise once again.

-- 
Conn V Copas
Information Technology Division
Defence Science and Technology Organisation
PO Box 1500
Salisbury            tel: +61 (0)8 25 95349
SA  5108             fax: +61 (0)8 25 95980
Australia       e-mail: cvc at itd.dsto.gov.au
-------------------------------------------