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 <[email protected]>: > > 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 <[email protected]> > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
