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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
