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

[Soeren Gebbert]

Hello Glynn,
I just searched for static variables in the grass libs. There are
hundreds of them .... .
It is impossible to replace them without re-designing and rewriting
most of the grass functionality.

I had the little hope to patch grass in a way that the core gis,
vector, database and volume
functionalities can be called from within multi-threaded java
applications like web services
especially WPS. Thats the reason why i designed the vtkGRASSBridge, to
enable native access to the grass libraries in java.

After counting the static variables and reviewing the code, i realized
this is an illusion.
The only way to call the grass functionalities from within a
multi-threaded java web container or an RCP
is to fork a process for each grass processing java module and connect
them via sockets and serialization with
the java threads in the Web/RCP container.

So a java visualization application based on a rich client platform
like netbeans or eclipse
using VTK for visualization of grass data is much more difficult to
implement and not very performancing. :(

What a pity.

To enable at least non multi-threaded continuous working programs
using grass libraries see below:

2009/9/23 Glynn Clements <glynn at gclements.plus.com>:
>
> Soeren Gebbert wrote:
>
>> thanks for clarifying this issue and for all the useful hints checking
>> the static variables.
>> I guess it will be really hard work
>> and mostly impossible to get GRASS running on long term processes.
>
> 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? :)

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

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?

Best regards
Soeren

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