Ivan Shmakov wrote: > > 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.
No, there's no need to re-open it (or otherwise "rewind" it). G_get_raster_row() takes the row number as an argument; nothing requires that you read the rows sequentially, or that you read each row only once. > > 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. To make concurrent access work, updating a map would need to be an atomic operation, so that any module which reads the map sees either the "before" version or the "after" version, and never sees an "in-progress" version. This means that while any module is in the process of opening the various elements that make up a map, the map cannot be replaced. The module wouldn't have to keep the map locked while processing the data; it could unlock it once it no longer needs to open any more files. Provided that modules were written to read all of the support files at the beginning, the lock could be released before it starts reading the actual map data. For output maps, the writer would write the data to a temporary file, and would only need to lock the map at the point that it is closed, for the time taken to rename the cell/fcell file and to write the support files. Deadlock is only possible if a module attempts to obtain a lock while it already holds another lock. I can't conceive of any situation where that would be necessary. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
