[GRASS5] Platform for next generation UI

[Glynn Clements]

Russell Nelson wrote:

>  > The problem is that reliability is subject to exponential decay. E.g. 
>  > if the probability of a module crashing is 0.01,
> 
> No, that's not it.  There are two sources of unreliability: repeatable
> and unrepeatable.  The first would include a request to do something
> which always exceeds the available resources, or a bug which cannot
> handle certain data.  The second would include an unreliable CPU
> (e.g. if the CPU fan has died), or a bug caused by an uncaught
> resource starvation.
> 
> If the unreliability is repeatable, then it's NOT subject to
> exponential decay.
> 
> If the unreliability is not repeatable, then it doesn't really matter
> if the sequence of operations occurs in separate programs or in one;
> either way the sequence is broken and needs to be restarted.

That's a completely separate issue.

I'm not talking about reliability in terms of whether or not an
operation succeeds, but in terms of how it fails.

If a standalone module fails, it doesn't really matter how. There
isn't a great deal of difference between segfaulting, calling exit()
straight away, or calling exit() after having deallocated memory,
restored global state etc.

OTOH, for a library function, it makes a great deal of difference how
failure is handled.

>  > 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.
> 
> There's two kinds of memory leaks: not freeing memory when you exit,
> and losing memory on an ongoing basis.  The first is not a problem.
> The second is a problem no matter what; if it doesn't bite you with a
> small data set, it will with a large one.  Data sets only get larger.

Standalone modules normally handle the latter (or at least try to),
but there's no reason for them to handle the former, so they don't.
OTOH, library functions need to handle both.

>  > > #3 is a reason NOT to split functions between processes.
>  > 
>  > Huh?
> 
> If you need data loaded, it makes more sense to load it once and share
> it between library calls, rather than to have to load it every time a
> program starts up.

OK, I see your point.

>  > Exactly. But that's the whole point. We aren't discussing creating a
>  > GIS from scratch, we're discussing where GRASS should go from where it
>  > is now. If you were writing a GIS from scratch, you would do it very
>  > differently to how GRASS has been written.
> 
> Maybe it's time to write a GIS from scratch, then, liberally borrowing
> from GRASS as appropriate?

My main point is that you aren't going to be able to borrow as much as
you might initially suspect, due to the mechanisms used for:

1. State initialisation (the loader initialises global variables from
the data and BSS segments at startup).

2. Resource deallocation (call exit()).

3. Error handling (again, call exit()).

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