On Thu, 22 May 2008, Glynn Clements wrote:
Paul Kelly wrote:
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.
But does that not mean that if there is a stale lockfile for whatever
reason, it can't be removed automatically and the user will never be able
to use that mapset? (I'm thinking that Windows users are especially
unlikely to go manually looking for the lockfile and deleting it.)
Correct.
Option 1:
One option would be to make etc/lock provide more detail if it fails
due to the lock being present, including the pathname of the lock
file, and a recommendation to manually delete it if you are certain
that no other GRASS sessions exist.
Option 2:
Another option is to change g.mapset to simply skip the locking step
on Windows. A user starts multiple sessions at their own risk.
Option 3:
Making locking actually work would require knowing how to check the
status of a process on Windows.
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?
If I changed this I would make $GISBASE/etc/lock issue a warning about
locking of mapsets against concurrent use not being enforced on Windows.
Paul
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
