Paul Kelly wrote: > So, I feel the idea behind Glynn's comments (and one that I guess I would > agree with) is that we encourage other projects to use GRASS by calling > the modules directly. As GRASS has so few developers compared to the > massive body of code, putting in extra development time to make GRASS work > in ways that have no benefit for GRASS is just too much effort.
That's about right. Maybe I can elaborate: 1. The GRASS libraries handle errors by calling exit(). This avoids the need for callers to explicitly handle errors and for either the caller or callee to perform cleanup. It's possible to avoid the call to exit() by installing an error handler which longjmp()s out; However: it is implied that calling G_fatal_error() relieves the caller of the responsibility to restore GRASS data structures to a consistent state. If you longjmp() out of the error handler, then make further calls to GRASS functions, they may crash. This is Not A Bug. Calling into GRASS after a fatal error *is* a bug. 2. The GRASS libraries don't bother tracking (and freeing) memory which would only represent a fixed overhead for a GRASS module, or which would typically not be freed until shortly before termination. If an operation uses a small amount of memory (e.g. a map name) and is typically performed once or a few times per map, we don't care about freeing it. A module will inevitably need some amount of memory for each map which it opens, and if the difference between freeing and not freeing means that the amount is 15Kb rather than 10Kb, then it doesn't really matter. It all gets returned to the OS when the module terminates anyhow. If you try to write a persistent application which continually opens and closes maps, eventually the accumulated leaks will cause it to run out of memory. This too is Not A Bug. Not isolating distinct operations in distinct processes *is* a bug. Both of these strategies make it much easier to both implement the GRASS libraries and to use them, and they work perfectly well for the libraries' intended purpose: writing GRASS modules. If it means that they aren't suitable for other purposes, that is Not A Bug. For any changes, the main concern is how those changes impact GRASS itself. If the changes impose extra effort on anyone writing GRASS modules, or (to a lesser extent) anyone modifiying the libraries, then those changes would be a net loss for GRASS. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
