real time GRASS

[Conn Copas]

p?19??95?05?59?32?pm at bnr.ca>
content-type: text/plain; charset=US-ASCII
organization: University of Illinois at Urbana
mime-version: 1.0
reply-to: grassu-list at max.cecer.army.mil
newsgroups: info.grass.user
originator: daemon at ux1.cso.uiuc.edu


Steve Dzurenko writes:
> 
> I am developing GRASS as a real time oceanographic
> survey tool.  I have a bunch of real time data
> acquisition programs which communicate with the 
> GRASS environment through the GRASS gis library
> calls G_getenv, G_setenv, etc.  
>
There is not really any such thing as 'the' GRASS 
environment; only the environment prevailing at the time any process (ie, user
command) is executed. Each process inherits the environment of the process
which invoked it, and may possibly scan the environment again during execution.
If those commands are being invoked interactively, then the
parent process is a shell, otherwise it could be a script or a C program.

What exactly do you mean by saying that your data acquisition programs
communicate with the GRASS environment? The environment is not a process, and
hence can't talk to anything. It would be possible, although unorthodox, for
your data acquisition programs to communicate with _GRASS_ by using the 
variables in the environment as a type of blackboard. What data is being passed
back and forth, and how is synchronisation being achieved?
>
> I think I am pushing the limits of GRASS as far
> as the environment variable file goes.  With so
> many calls to change GRASS environment variables
> and write the environment file, programs are
> crashing quite frequently.  I think this is due
> to attempts to write the GRASS environment file
> while another program is attempting to do the 
> same thing.
> 
As far as I know, Unix does not store environment variables in a file, as that
would be slow. GRASS processes, however, effectively store _some_ environment
variables in the $GISRC file. You need to establish whether
Unix is complaining about asynchronous updates of that file by multiple
processes (which is highly unlikely), or whether GRASS processes are
interfering with each other (for example, by changing the currently selected
MONITOR whilst another process is executing a sequence of display commands).
(a) are display processes even involved? (b) if so, how many different display
processes does the one parent process invoke? (b) put a diagnostic on G_getenv
and G_setenv and tell us which processes are reading/writing which environment
variables in which sequence.

-- 
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
-------------------------------------------