>>>>> Glynn Clements <[EMAIL PROTECTED]> writes:
>> BTW, is there a way to ``lock'' on a raster (or its data at least),
>> so that it could be opened (or rewound) multiple times and, e. g.,
>> `G_get_raster_row' would return the same data, even if the raster
>> was, e. g., renamed meanwhile?
> That's already the case.
> When a raster is opened for write, the data is written to a temporary
> file in the <mapset>/.tmp/<hostname> directory. When the raster is
> closed, the temporary file is moved into place with rename().
> Any process which has the raster open for reading will be unaffected
> by all of this, so long as it keeps the raster open (if it closes and
> re-opens it, that's a different issue).
It seems that you've missed my point. I wish to process the
whole raster with G_get_raster_row () once, and then another
time from the start. The only way to do it that I know is to
close and re-open it, which is ``a different issue'', indeed.
> Note that this typically won't work on Windows. If a module tries to
> replace a raster while it's open, the renaming step will fail.
> A more signficant issue for concurrent access is the potential for
> race conditions between opening the various files which make up a
> raster (cellhd, cell/fcell, categories, colour table, history, etc).
> To minimise the risk of race conditions, modules should ideally read
> all support files at the start, rather than waiting until they have
> finished reading the raster data.
Quite so. Although I have a few ideas on how to avoid it.
> To have concurrent access working properly, we would need to add
> explicit locking to all modules. Actually, we might be able to do it
> in g.parser, at least for modules whose options contain complete
> information (i.e. not modules which derive the names of output maps
> from the names of the input maps).
So that, e. g., renaming would be impossible without all the
processing of the raster finished? It doesn't seem to be a
particulary bright solution. At least, it may bring deadlocks
to GRASS, and it seems to complicate parallel execution in
general as well.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
