[GRASS5] Re: Multiuser grass projects

[Martin Pokorny]

On Mon, 30 Jun 2003, Glynn Clements wrote:
> Locking individual files in G_open_cell() etc won't work as a
> general solution; there just isn't enough context.
> 
> A module may read and write several files, and to be safe,
> everything which it reads or writes must be locked against all other
> accesses from the point that the first file is opened to the point
> that the last file is closed.

I see---that makes perfect sense. I'm a GRASS newbie, but I want to
learn more so I can make some programming contributions. Thanks for
the useful information.

> Actually, even locking the entire mapset doesn't quite achieve this. 
> Most GRASS modules can read maps from mapsets other than the current
> one. If another session happends to be modifying that mapset, the
> result is undefined.
> 
> Modifications to the actual raster data aren't a problem;
> G_open_cell_new() etc write to a temporary file which is renamed
> upon closure. Unix filesystem semantics ensure that, if another
> session was reading the file, it's contents will still be available
> to the reader even after it has been "deleted" (at least on a real
> Unix; this isn't true for Cygwin, but I doubt that a Cygwin
> installation will be multi-user).
> 
> However, if a module reads multiple components (cellhd, data, colour
> table, history, ...) from a map in another mapset, and another
> session is modifying that map, the various components may not
> correlate.
> 
> Just because nobody has reported having been bitten by this, it
> doesn't mean that it can't happen.

I won't argue with that. I've learned that, generally, "can" implies
"will" in programming (and it throws off your reasoning to assume
otherwise).

Cheers,
  Martin

-- 
Martin Pokorny
Tucson, AZ, USA