[GRASS-dev] Locking is not supported on Windows

[Paul Kelly]

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