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

GRASS GRASS developer
1

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

What a pity.

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

2009/9/23 Glynn Clements <glynn@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? :slight_smile:

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@gclements.plus.com>

2

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? :slight_smile:

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@gclements.plus.com>

3

Soeren wrote:

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

perhaps the gdal-grass-plugin is an option there.

Hamish