[GRASS5] Platform for next generation UI

[Russell Nelson]

Glynn Clements writes:
 > Russell Nelson wrote:
 > 
 > >  > 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.

Yeah, on second thought, you're right; I apologize.  It *is* easier to
write code if it's okay if the code can exit.  If you look at qmail's
source code (written in C), some programs simply exit immediately if
they run out of memory.  There's nothing more to be done, so they may
as well indicate a temporary failure and be done with it.  Other
programs (like qmail-send) CANNOT under any circumstances exit
prematurely, so for example if they cannot get more memory or write to
a file, they retry the operation until it succeeds.

 > 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.

 > 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.

 > > #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.

 > 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 blog is at     blog.russnelson.com         | A computer without Python is
Crynwr sells support for free software  | PGPok | like a CPU without memory:
521 Pleasant Valley Rd. | +1 315-323-1241       | it runs, but you can't do
Potsdam, NY 13676-3213  |     Sheepdog          | anything useful with it.