
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sorry for this mistake,<div>we've sent this mail 30 minutes before the time I have to leave the conference center ....</div><div><br></div><div>I will try to be more precise and to give my new thoughts about this issue of recode partially the main function. In fact I think about creating a new environment specific to ZOO Services redirecting std output, input and error and handling the exit function using an internal ZOO Kernel one ... let me think again to this idea I get into the plane about this remarks,</div><div><br></div><div>thank you again Soeren for sharing your thoughts !</div><div><br></div><div>Best regards, <br><div><br><div>Début du message réexpédié :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>De : </b></span><span style="font-family:'Helvetica'; font-size:medium;">Gérald Fenoy <<a href="mailto:gerald.fenoy@geolabs.fr">gerald.fenoy@geolabs.fr</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date : </b></span><span style="font-family:'Helvetica'; font-size:medium;">7 novembre 2009 04:13:19 HNEC<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>À : </b></span><span style="font-family:'Helvetica'; font-size:medium;">Soeren Gebbert <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Objet : </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Rép : [Zoo-discuss] About ZOO Project</b><br></span></div><br><div>Hi Soeren,<br><br>Sorry for the delay in my response.<br><br><br>Le 4 nov. 2009 à 12:35, Soeren Gebbert a écrit :<br><br><blockquote type="cite">Hello Venkatesh,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2009/11/3 Venkatesh Raghavan <<a href="mailto:raghavan@media.osaka-cu.ac.jp">raghavan@media.osaka-cu.ac.jp</a>><br></blockquote>.....<br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">have all the GRASS functions in the command repository.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This way we will be able to run any GRASS command and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also code new command using GRASS libraries.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Ok, having the grass libraries in the ZOO kernel, allows developers to<br></blockquote><blockquote type="cite">develop the business logic (in case of an WPS server the geo<br></blockquote><blockquote type="cite">processing) of the WPS server using the ZOO api?<br></blockquote><br>Yes.<br><br><blockquote type="cite">I assume that the ZOO kernel uses threads to handle requests and to<br></blockquote><blockquote type="cite">execute the business logic. So we have a multi-threaded environment?<br></blockquote><br>We use fork to manage the request. We do not have multi thread environment.<br>if the process fails, ZOO kernel still exists in memory.<br><br><blockquote type="cite">Linking and using the GRASS libs in a multi-threaded environment will<br></blockquote><blockquote type="cite">bring two major issues:<br></blockquote><blockquote type="cite">1.) GRASS libraries are not thread safe<br></blockquote><br>Yes, as many other API's like MapServer etc.<br><br><blockquote type="cite">* Most of the library functions using static variables for computation<br></blockquote><blockquote type="cite">* parallel access to the vector database is AFAIK not allowed<br></blockquote><blockquote type="cite">* to enable multi-threading support for GRASS libraries, a major<br></blockquote><blockquote type="cite">update to GRASS must be done<br></blockquote><br>Yes, maybe but ZOO does not plan to do this, presently.<br>It would be great if someone can address these issues.<br><br><blockquote type="cite">2.) Many GRASS libraries call exit() on error<br></blockquote><br>So only child process will exit since ZOO Kernel still exists in memory.<br><br><blockquote type="cite">* In case an error occurred exit() is called so the WPS server will<br></blockquote><blockquote type="cite">shutdown. I assume that is not practical ;)<br></blockquote><br>Agreed.<br><br><blockquote type="cite">* the error function call which invokes the exit() call can be<br></blockquote><blockquote type="cite">replaced using G_set_error_routine()<br></blockquote><br>OK, maybe better in any case. G_set_error_routine have only to return SERVICE_FAILED and the error message.<br><br><blockquote type="cite">* To save the stack and assure a valid library state the combination<br></blockquote><blockquote type="cite">of setjmp and longjmp must be used. This is implemented in<br></blockquote><blockquote type="cite">vtk-grass-bridge. Have a look at this code:<br></blockquote><blockquote type="cite"><a href="http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx">http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx</a><br></blockquote><blockquote type="cite"><a href="http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h">http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h</a><br></blockquote><br>Nice, we will have a look.<br><br><blockquote type="cite">* The GRASS libs need to be patched to assure a valid library state<br></blockquote><blockquote type="cite">in case the error function using setjmp/longjmp was called (close open<br></blockquote><blockquote type="cite">file handler, release unused memory, reinitialize static variables and<br></blockquote><blockquote type="cite">so on ...)<br></blockquote><br>Should be tricky. Wonder if we should consider SEXTANTE. Wonder if<br>SEXTANTE is thread safe?<br><br><blockquote type="cite">Wow, 20 GRASS examples is a lot ... . I have read the trac documentation<br></blockquote><blockquote type="cite">and lurked a bit in the source code. I think i need more investigation<br></blockquote><blockquote type="cite">to fully understand<br></blockquote><blockquote type="cite">the functionality of the ZOO kernel. :)<br></blockquote><br>Aim for 20, that we could be sure to acheive 10.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Ah, ok gdal read and write directly raster and vector data from grass mapsets?<br></blockquote><blockquote type="cite">Thats cool. I think additionally the creation of a temporal mapset for every<br></blockquote><blockquote type="cite">response is still needed (see PyWPS). Otherwise grass modules will interfere<br></blockquote><blockquote type="cite">each other while computation.<br></blockquote><br>Have to check about the vector. GRASS raster write is supported by GDAL.<br>Maybe temporal Mapset is necessary.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">...<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Is there a way to connect the grass modules as shared objects to zoo to support<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">i.e. the suspending of long running wps processes (without the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">modification of the modules)?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sure, you only have to create a shared library which use GRASS module<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which you want to use as a service. Suspend is already implemented<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">if you use the storeExecuteResponse already in WPS specification.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If you use this parameter this will imply that the ZOO kernel will<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fork to spawn new process which can run your function without<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">having to wait for response which was already provided by the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">parent process.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Currently all GRASS modules are stand alone C programs, shell- or python<br></blockquote><blockquote type="cite">scripts. In case of shell scripts, i have no clue how to create shared<br></blockquote><blockquote type="cite">libraries from.<br></blockquote><blockquote type="cite">In case of the GRASS modules implemented in C, the main functions need<br></blockquote><blockquote type="cite">to be replaced<br></blockquote><blockquote type="cite">with a function which can be called from ZOO to invoke the service.<br></blockquote><blockquote type="cite">What have to be done in GRASS to support this:<br></blockquote><blockquote type="cite">1.) In every GRASS module which should be used in ZOO the program<br></blockquote><blockquote type="cite">structure needs to be changed:<br></blockquote><blockquote type="cite">* Tuning the Makefiles to create an executable and a shared object<br></blockquote><blockquote type="cite">* #ifdef switches to support the default main() function and the<br></blockquote><blockquote type="cite">replacement function called from ZOO<br></blockquote><blockquote type="cite">* Creation of a header file declaring the function which should be<br></blockquote><blockquote type="cite">called from ZOO to invoke the module as a service<br></blockquote><blockquote type="cite">** i.e: r.los -> r_los_main(int argc, char **argv);<br></blockquote><br>sounds like a lot of work.can we find a developer to do this ?<br><br><blockquote type="cite">* ZOO need to provide the command line options for every module as char arrays<br></blockquote><br>ZOO Kernel use special data structure called maps.<br><br><blockquote type="cite">2.) All modules call exit() in case of an error and are not thread safe<br></blockquote><blockquote type="cite">* The error routine can be replaced using G_set_error_routine(), but<br></blockquote><blockquote type="cite">each module must be reviewed and patched to clean up before the the<br></blockquote><blockquote type="cite">error function is called and to return properly to the ZOO kernel.<br></blockquote><blockquote type="cite">Thats a lot of work!<br></blockquote><br>I think you're right, it seems to be a lot of work. Is there any generic way to achieve this goals ?<br><br><blockquote type="cite">* Because the GRASS libraries are not thread safe, the module are<br></blockquote><blockquote type="cite">neither. And in case the GRASS libs will be thread safe some times,<br></blockquote><blockquote type="cite">the modules still need to be reviewed for multi threading support.<br></blockquote><blockquote type="cite"><br></blockquote><br>Yes.<br><br><blockquote type="cite">In case grass modules are called from forked processes and not from<br></blockquote><blockquote type="cite">threads of a single process, there should be no problems.<br></blockquote><blockquote type="cite">My suggestion is to run GRASS modules as separate processes in<br></blockquote><blockquote type="cite">temporal created mapsets.<br></blockquote><br>In fact this is a good sugestion.<br><br>I will answer in more detail about the securre connexion later.<br><br>Gérald & Venka<br><br>ZOO Tribe Monkeys.</div></blockquote></div><br><div>

<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><span class="Apple-style-span" style="font-size: 12px; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Gérald Fenoy</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="mailto:gerald.fenoy@geolabs.fr"><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; ">gerald.fenoy@geolabs.fr</span></a></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">GEOLABS</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Siège social :</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Futur Building I</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1280, avenue des Platanes</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">34970 Lattes</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Tél. fixe : 04 67 53 67 37</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Tél. portable : 06 70 08 25 39</div></span></div></span>

</div>

<br></div></body></html>