[GRASS-dev] Re: [GRASS-user] The tomcat shut down when encounter
some error grass commond
soerengebbert at googlemail.com
Wed Sep 23 18:14:45 EDT 2009
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
Sorry, i did not quite understand what "pollute the global namespace"
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.
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
but providing a pointer of a region to the opening function?
Glynn do you think this is possible without an overhead of work on
> Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev