[GRASS-dev] Locking is not supported on Windows

[Glynn Clements]

marco.pasetti at alice.it wrote:

> there's a thing that I never understood: why Locking is not supported on Windows?
> Then:
>
> 1) what is exactly locking? I tried to find it on the programmer's
> manual, but without success

Locking is the process of first checking that the .gislock file
doesn't exist, then creating it.

This ensures that you cannot have two GRASS sessions with the same
current mapset.

> 2) I noticed that, when opening a location/mapset, GRASS doesn't
> create the .gislock file, as done on linux;

The etc/lock program which creates the .gislock file doesn't work on
Windows. The program is created, but it just generates the "Locking is
not supported on Windows!" warning and exits without creating the lock
file.

AFAICT, this is excessive. The only part of that module which is
inherently non-portable is the check for a stale lock, i.e. if the
process which created the lock file no longer exists.

It should be possible to just skip that check on Windows, rather than
skipping locking altogether.

> without the .gislock
> file it's impossibel to change the working environment (that is the
> mapset...) by the g.mapset module

Are you sure? AFAICT, etc/lock should always succeed on Windows, i.e. 
it won't stop you from having two sessions with the same current
mapset. You will get a warning, but the mapset should still be
changed.

If g.mapset doesn't work, you can always change the GISDBASE,
LOCATION_NAME and MAPSET variables directly with g.gisenv.

Paul Kelly wrote:

> If you start GRASS using grass63.bat (not grass63.sh), yes, you are 
> correct that that won't work. I deliberately left it out of init.bat at 
> the time I wrote it as it would have been a lot of extra work to implement 
> it

Where is the problem? Obtaining the PID?

In the worst case, you could just create a lock file with a PID of
zero. Assuming that the find_process() check is removed from etc/lock
(kill() doesn't exist on Windows), the actual PID written to the file
won't matter.

> and it wasn't needed to get basic GRASS functionality working on 
> Windows without the requirement for a Unix shell (which was my goal at the 
> time). You can simply exit and restart GRASS if you want to change the 
> mapset or location.

Or use g.gisenv.

> I believe the facility to change mapset or location without exiting and 
> restarting GRASS (and hence also this .gislock system) was added by Radim 
> Blazek some time during the development of version 5.7 (which eventually 
> became 6.0).

Actually, adding the ability to change the database/location/mapset
within a session was primarily an issue of changing scripts to get the
information from g.gisenv rather than relying upon the environment
variables being set.

Originally, Init.sh copied the GRASS variables into the environment,
and scripts just used the environment variables directly. This meant
that changing the variables with g.gisenv would only affect C modules
(which used $GISRC), but not scripts.

Radim then wrote g.mapset, which provides a more convenient mechanism
to change the variables (i.e. separate database= etc options rather
than using set=GISDBASE=...), as well as correctly handling locking
(i.e. obtaining the lock for the new mapset and releasing the existing
lock).

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