[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