Hi, 2013/7/7 Štěpán Turek <[email protected]>: > Hi, > > > yes, you can just run your command giving the right environment variables... > > > I have just one more question. > > > Will it work properly when I will call some function from C libraries: > > Im my case it is something like this: > > int I_ComputeScatts(struct Cell_head *region, struct scCats * scatt_conds, > const char ** bands, > int n_bands, struct scCats * > scatt_plts, const char ** cats_rasts)
Please use the GNU/GRASS style to implement new C library functions[1]. > > scatt_conds are selected areas in open scatter plots and scatt_plts there > are returned computed scatter plots. Let say that this function will be > called in separate process form wxGUI created by multiprocessing module. > And in this function there is used raster library. > > Is it (or can be) this raster library independent form raster library loaded > to wxGUI and from the other processes created from wxGUI? Yes, it is. The new process has its own environment that is not shared with other process. It will inherit the environment from its parent process and can modify its own environment[2,3,4]. > > Let say that this function will call Rast_set_window function. Will be > raster region set only in scope of the separate process or also out of it? If you use Rast_set_window() in the new process the computational region will only be set for this process. Be aware that you must use Python objects to transfer the data from the child process to its parent process using a queue[5]. I think that numpy array objects should work. [1] http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING#L201 [2] https://en.wikipedia.org/wiki/Unix_process [3] https://en.wikipedia.org/wiki/Child_process [4] https://en.wikipedia.org/wiki/Parent_process [5] http://docs.python.org/2/library/multiprocessing.html#multiprocessing.Queue Best regards Soeren > If the libraries are independent it solves the issue. > > > Best > > Stepan _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
