[GRASS-dev] Re: [GRASS-user] The tomcat shut down when encounter some error grass commond

[Glynn Clements]

Soeren Gebbert wrote:

> > It isn't just that it's a lot of work to change it, but that it
> > potentially causes problems for code which uses the libraries (e.g.
> > simply making the variables non-"static" pollutes the global
> > namespace).
> 
> Sorry, i did not quite understand what "pollute the global namespace"
> exactly means,
> well i am not a native speaker and not a C expert, so can you please
> provide an example? :)

If two libraries both export a symbol named e.g. "name", you'll get a
conflict if you use both libraries from the same program. Depending
upon the platform, you may get an error, or you may end up with the
variables being merged into a single variable.

This isn't a problem if the variable isn't exported (i.e. declared
with the "static" qualifier). But you have can't use "static" if the
variable needs to be accessible in more than one file.

> > That could be gotten around by moving all of the static data for each
> > library into a single "state" variable. That in itself isn't an issue,
> > but you have to remain vigilant for developers adding new static
> > variables ad-hoc.
> 
> An other approach might be the implementation of reset functions in
> every source file which uses
> static variables. The reset function can be called  for a fine grain
> reset approach or all together
> in a single reset function which collects all distributed reset functions.
> 
> i.e:
> New reset functions like:
> 
> G_reset_geodesic_equation in lib/gis/geodesic.c
> G_reset_window in lib/gis/get_window.c
> G_reset_cell_area_calculations in lib/gis/area.c
> 
> And so on ...

That will get around the namespace issue.

However, it doesn't really help with multithreading. For that, you
would want to store all of the static data in a library in a state
structure, and give each thread a pointer to a separate state
structure (e.g. pthread_setspecific).

> It would also be great to open raster maps without setting the global
> window variable
> but providing a pointer of a region to the opening function?
> Glynn do you think this is possible without an overhead of work on
> other functions?

The main problem here is that the mapping between the region grid and
the raster grid is recalculated whenever you change the region, so
that all maps are read and written at a single resolution. That isn't
a particularly common operation, but it is used (e.g. r.resamp.*) and
needs to be supported in some way.

This is one area which could do with an overhaul, but it's a
significant architectural change rather than modifying a few
functions.

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