[GRASS5] some thoughts

[Roger Bivand]

On Fri, 18 Jan 2002, Glynn Clements wrote:

> 
> The main advantage of this approach is the robustness provided by
> "insulating" the commands within separate processes. If a specific
> command segfaults, exhausts memory, calls exit() etc, it doesn't take
> down the entire session. Also, system resources (memory, file
> descriptors, etc) are guaranteed to be freed.
> 
> This means that we don't have to get rid of every single crash bug,
> memory leak, and exit() call before the resulting system becomes
> usable.
> 
....
> 
> Ultimately you can only get so much integration before separate
> processes start to become a problem. But eliminating the exit() calls,
> opportunities for fatal errors[1] and memory leaks isn't going to
> happen overnight.
> 
> [1] By which I basically mean crashes. G_fatal_error() can be modified
> to allow a "fatal" error handler to be installed which could call
> setjmp() rather than exit(). This would allow "exception" style error
> handling rather than having to pass NULL/-1/whatever all the way up
> the call stack.
> 
> 
The R interface "takes over" error handling from libgis.a as:

void R_G_init(char *name) {

	G_set_error_routine(R_handler);
	G_sleep_on_error(0);
	G_gisinit(name);
}

with R_handler() being a simple function that passes the error on within
R. If modules never use exit() but only G_fatal_error(), this works
smoothly in my experience.

Interfaces to other programmes also need clean command line style argument
sets which can be used through system calls - though in fact VASK-style
interfaces still work from within R in a terminal window.

On a different aspect, I've thought of some kind of daemon process too,
but as an auditing monitor for metadata, giving some kind of tag to
withdrawals and commits to the database, not least for external programmes
to talk to, so that metadata is kept clean for data objects being moved in
and out of the system. However, I'm sure there must be better ways of
doing this (in S/R with sticky attributes on objects, perhaps - a site
object might have a location/projection/... tag as an attribute). As it
is, lots of metadata is just in the database, but once data has been
extracted, it may easily be lost.

Roger

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.