[GRASS5] Platform for next generation UI
glynn at gclements.plus.com
Sat Jan 7 11:03:43 EST 2006
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.
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.
> > 3. You need to be able to re-initialise the state at each invocation.
> > Currently, the core GRASS libraries use a lot of static data. This
> > data is initialised automatically at startup, and is discarded at
> > termination. For a library, you would have to be able to explicitly
> > re-initialise all of that data before invoking each command.
> #1 and #2 are reasons to split functions between processes.
> #3 is a reason NOT to split functions between processes.
> I would argue against you, but you're doing a perfectly fine job of it
> yourself. In principle, you're not disagreeing with me. You're just
> pointing out that an artifact of the implementation would make
> creation and use of a library difficult.
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.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev