[GRASS5] Region lock

GRASS GIS GRASS GIS developer
1

Does it make sense to add region lock?
Region (WIND file) could be locked by modules until call to
G_get_window and modules changing region (d.zoom, g.region) could check if the region is in use.

OTOH,
1) G_get_window is usually called in first rows of main()
    so that user cannot start others module before it is called
2) it does not resolve problem in scripts on background which is
    a real pain

Radim

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To us, yes (e.g. for r.le, r.drain, etc.).
Paolo

At 16:44, martedì 30 novembre 2004, Radim Blazek has probably written:

Does it make sense to add region lock?
Region (WIND file) could be locked by modules until call to
G_get_window and modules changing region (d.zoom, g.region) could check
if the region is in use.

OTOH,
1) G_get_window is usually called in first rows of main()
so that user cannot start others module before it is called
2) it does not resolve problem in scripts on background which is
a real pain

Radim

- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBrJ8b/NedwLUzIr4RApMQAKCvq485x6DhG1yahxqivbZvAn5W/wCdGOkZ
TCOHThirryD+634HS1evPQ8=
=I438
-----END PGP SIGNATURE-----

3

Radim Blazek wrote:

Does it make sense to add region lock?

AFAICT, no.

Is there a specific scenario where you think that a lock would be
useful?

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

4

Glynn Clements wrote:

Radim Blazek wrote:

Does it make sense to add region lock?

AFAICT, no.

Is there a specific scenario where you think that a lock would be
useful?

Always when user run a raster module via GUI or on background and then he continues to change the region g.region/d.zoom. It is quite common, if user has to wait until the background job finishes he usually query maps in monitor using d.zoom/d.pan. This is especially danger for scripts.
No errors are reported, but results are wrong (e.g. r.what in loop).

I cannot say how danger it is for single modules. For scripts it IS problem. We could add g.regionlock and encourage users to start scripts
with this module.

But it can be done also later, I have moved it to TODO > 6.0.

Radim

5

Radim Blazek wrote:

>>Does it make sense to add region lock?
>
>
> AFAICT, no.
>
> Is there a specific scenario where you think that a lock would be
> useful?

Always when user run a raster module via GUI or on background and then
he continues to change the region g.region/d.zoom. It is quite common,
if user has to wait until the background job finishes he usually query
maps in monitor using d.zoom/d.pan. This is especially danger for scripts.
No errors are reported, but results are wrong (e.g. r.what in loop).

Right. But I don't think that this can be fixed with a generic
mechanism.

The problem is that the top-level (e.g. the program which repeatedly
runs r.what) must hold the lock, not the lower-level program (e.g.
r.what).

I cannot say how danger it is for single modules. For scripts it IS
problem. We could add g.regionlock and encourage users to start scripts
with this module.

Right. It's only likely to be an issue for scripts and programs which
spawn other programs where the region is required to remain constant
for multiple related processes. Normal programs read the WIND file
once then use that data for their duration.

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