[GRASS-dev] grass is a monad?

[Maris Nartiss]

Some rumbling form bad code author.
Still I don't see why GRASS modules would not benefit from ability to
clean up after themselves in case of failure. Removing temporary maps,
closing open DB connections etc. are good reasons why GRASS modules
should do error checking by themselves, unless it IS a FATAL error
(one that means serious module code error or something terribly wrong
with data files/software/hardware when any future action might result
in even larger disaster).
IMHO decisions when and how to push the Big Red button should be left
to module authors. Library functions returning i.e. -1 is not so big
issue to check in module code and then call lethal error there
(possibly after rm'ing temporary files etc.).

Just my 0.002.
Maris.


2010/1/14, Glynn Clements <glynn at gclements.plus.com>:
>
> 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 <glynn at gclements.plus.com>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>