[GRASS-dev] Re: [GRASS-SVN] r40083 - grass/trunk/lib/raster

[Glynn Clements]

Markus Neteler wrote:

> > Author: glynn
> > Date: 2009-12-20 01:20:23 -0500 (Sun, 20 Dec 2009)
> > New Revision: 40083
> >
> > Modified:
> >   grass/trunk/lib/raster/R.h
> >   grass/trunk/lib/raster/closecell.c
> >   grass/trunk/lib/raster/get_row.c
> >   grass/trunk/lib/raster/opencell.c
> >   grass/trunk/lib/raster/put_row.c
> > Log:
> > Keep null bitmap open
> 
> Is this relevant for 6.4 or 6.5?

I think that it may be too disruptive for 6.4. It's a fairly
fundamental change to the core raster I/O code.

OTOH, all of the possible solutions to bug #837 are at least
moderately disruptive.

The short version is that calling G_find_* (and thus G_open_*) tends
to leak memory. This wouldn't normally be considered a problem, except
that the null bitmap handling calls these functions for every few rows
of input data, so it grows over time rather than be a fixed, per-map
overhead.

There are enough issues with the null bitmap handling that, for 7.0,
I've decided to fix it properly (it now opens and closes the null
bitmap along with the rest of the map, which improves performance at
the expense of using more file descriptors). But the open/close logic
is complicated enough that subtle bugs could hide in there for a long
time. So if we did this for 6.4, and it did introduce a bug, there's a
good chance that it wouldn't be found before an eventual 6.4 release.

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