[GRASS-dev] Locking is not supported on Windows
Glynn Clements
glynn at gclements.plus.com
Sat May 24 19:31:03 EDT 2008
Paul Kelly wrote:
> I think all three of these options are feasible. Option 2 is starting to
> appeal to me most. I thought of doing some research into Option 3, but
> then I thought it isn't really necessary, that the mapset locking is
> perhaps a bit over-protective. As far as I can think, it is possible to
> run multiple sessions in the same mapset anyway, if you use WIND_OVERRIDE
> or GRASS_REGION, so there is really no fundamental need to lock a mapset -
> it's just an extra encouragement/nagging to enforce good working
> practices. Or have I missed something?
You also need to ensure that you don't try to modify a map (etc) from
two sessions concurrently.
OTOH, even with two sessions using different mapsets, you can
theoretically run into problems with one session reading a map which
is being modified by the other session. But I have yet to hear of
anyone actually being bitten by it.
But, yes, WIND is the main issue, and WIND_OVERRIDE should deal with
that (except that the wxPython GUI reads the WIND file directly, which
is a pretty serious bug).
The VAR file could potentially be an issue, as could the CURGROUP and
CURSUBGROUP files. There may be other files which I have overlooked.
Personally, I would like to see both WIND and CUR[SUB]GROUP moved into
$GISRC.
The database stuff in VAR should also be able to be overridden by
$GISRC, with VAR being used as a fallback (similar to DEFAULT_WIND for
the region).
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list