[GRASS-dev] Using GRASS in long running and multithreaded applications Was: Re: The tomcat shut down ...

Glynn Clements glynn at gclements.plus.com
Sat Sep 26 09:04:06 EDT 2009

Hamish wrote:

> > The main issue for concurrent reading is that the raster
> > library caches the current row, so that upscaling doesn't
> > read and decode each row multiple times. That's problematic
> > if you want multiple threads reading the same map.
> to me multi-threaded multi-map read does not seem so exciting.
> typically both maps are in the same GISDBASE, so on the part of
> the same disk drive, which can only physically read one thing
> at a time, and asking the drive to jump around non-sequentially
> to read two maps at once would just slow the overall read down.

That assumes that the data isn't buffered in RAM. Often, the file will
have been created by the previous command, an will stil be in RAM, so
read() is just copying RAM.

Also, the decoding and rescaling overhead may mean that the process
isn't actually I/O bound.

And if you have more than one input map, or you're working on a
multi-user system, the I/O will typically be non-sequential anyhow.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list