[GRASS-dev] [bug #4368] (grass) g.parser: pass through --o

[Glynn Clements]

Hamish wrote:

> > The point remains that using fixed files within the mapset directory
> > (WIND, VAR) means that you can only have one instance of that state
> > per mapset. That's fine for the historical "command-line session"
> > usage, but problematic for other cases.
> 
> Do "other cases" ensure data integrity? Or does that require something
> ugly like lock files for each map? (e.g. made even worse: existing gis.m
> problem of r.colors etc changes not triggering an updated PPM in the
> display layer cache). I don't mind the restriction of one [read-write]
> session per mapset. If I want to access a map I can always start in a
> new mapset and call map at first_mapset [read-only].

For the foreseeable future, each mapset will be limited to either one
read-write session or multiple read-only sessions, but not both.

However, the notion of "write" should be restricted to modifying
actual /maps/. The multiple-readers case should allow each reader to
have a different region, different monitor, different settings for any
variables, etc. Which precludes using any fixed files such as WIND or
VAR.

FWIW, most of the concurrency issues still apply even if you read maps
from a different mapset. If a writer is modifying the mapset which you
are reading, you could end up reading a map (or even a file) which is
in an inconsistent state.

In terms of reliably supporting both a writer /and/ one or more
readers, there are two levels: individual files and entire maps.

Ensuring that a reader doesn't get to see an inconsistent file is
simple enough. The raster cell/fcell files are already handled
correctly, but the code which writes out support files (cellhd, range,
colr etc) needs to be modified to behave similarly (i.e. write to a
temporary file then rename() it over the original file once it has
been completely written).

Supporting atomic updates of entire maps would be significantly
harder. It might be possible to avoid having to modify all of the
individual modules by writing all output files to a temporary
directory then having an atexit() handler rename them to their correct
locations.

Changing the layout so that all of a map's files reside within a
single directory would simplify this, as you just need to replace one
directory with another, rather than replacing multiple files.

Even so, you can't atomically replace a directory. You can get quite
close by renaming the old directory out of the way, renaming the new
directory into place, then removing the old directory, but that still
leaves a small window where the directory doesn't exist. True atomic
updates would require that maps are accessed via symlinks; those can
be replaced atomically.

> > The simplest fix is to repeat the hack used for WIND (provide an
> > environment variable to override it), but ultimately we need to
> > consider better mechanisms for saving state.
> 
> FWIW, I am a fan of retaining a WIND file per mapset.

There is no problem in retaining it for legacy usage, but allowing
multiple readers requires that they use a different mechanism. Which
basically means that everything needs to use the new mechanism,
otherwise you need some mechanism to decide who gets to use the WIND
file.

-- 
Glynn Clements <glynn at gclements.plus.com>