[GRASS5] Platform for next generation UI

[Glynn Clements]

> >  > Re-working the guts of each module for use in a library which is to be
> >  > used by a long-lived application would be a lot of work, for several
> >  > reasons:
> >  > 
> >  > 1. You need much greater robustness.
> >  > 2. You need to make more effort to prevent memory leaks.
> > 
> > Urgh.  It sounds to me like you're saying that the GRASS is so poorly
> > written that one function needs to be protected from another by the
> > kernel's inter-process protection.
> 
> Well, that's the implication of 1, and in a sense it's true, although
> your phrasing isn't entirely fair.
> 
> The problem is that reliability is subject to exponential decay. E.g. 
> if the probability of a module crashing is 0.01, the probability of it
> not crashing is 0.99 and the probability of running 100 commands in
> succession with none of them crashing is 0.99^100 = 0.36.
> 
> IOW, if you want reasonable robustness for the application as a whole,
> the robustness of each command needs to be very much higher,
> essentially "bulletproof". The code in the GRASS modules wasn't
> originally written to such constraints; it's reliability is merely
> reasonable for its intended use.
> 
> Regarding point 2, if you're writing a standalone executable, not
> bothering to free memory isn't a bug. There is no reason to do this
> when the the kernel is going to do it for you.

One point which I forgot until after I'd sent this.

There are some similarities between points 1 and 2, which ties in with
point 3. In the same way that standalone modules leave initialising
state to the loader, and deallocating memory to the kernel, they deal
with errors in a similar manner: call the fatal error routine,
G_fatal_error(), which terminates the program, deallocating all memory
and discarding the global state.

While it's possible to install your own handler for fatal errors, any
code which calls G_fatal_error() relies upon the fact that it doesn't
return, and won't make any attempt to clean up whatever global state
it has been using.

Again, this is an entirely reasonable approach for a standalone
module, but won't work in a library.

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