[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
