[GRASS-dev] [GRASS GIS] #2134: Create a general exit-safe interface to C libraries

[GRASS GIS]

#2134: Create a general exit-safe interface to C libraries
--------------------------------------------------+-------------------------
 Reporter:  wenzeslaus                            |       Owner:  grass-dev@…              
     Type:  enhancement                           |      Status:  new                      
 Priority:  normal                                |   Milestone:  7.0.0                    
Component:  Python ctypes                         |     Version:  svn-trunk                
 Keywords:  G_fatal_error, exit, multiprocessing  |    Platform:  All                      
      Cpu:  Unspecified                           |  
--------------------------------------------------+-------------------------

Comment(by wenzeslaus):

 Replying to [comment:6 glynn]:
 > Replying to [comment:4 zarch]:
 >
 > > Or as already suggested by Glynn (#1646) wrap the G_add_error_handler,
 >
 > Using an error handler allows you to avoid process termination. But once
 a fatal error has occurred, you cannot safely call any GRASS function;
 doing so may well result in a segfault.

 One of the issues which `G_add_error_handler` is trying to solve is to
 provide meaningful error message to the user. For example, failing to open
 some temporary file causes `exit` with "`No such file /tmp/kjewbf8d38dj`".
 This does not help user nor programmer to understand that the error
 occurred (when does this happened, what is the stack trace, what are
 consequences and what are suggestions to solve it). In other words,
 sometimes the message provided by `G_fatal_error` caller is too low level.

 Python `RPCServer` with wrapper functions throwing exceptions would help
 to solve this issue.  But it seems to me that #1646 remains valid for
 pyGRASS (and possibly others) and C code itself.


 Replying to [comment:7 huhabla]:
 > In my opinion the RPC approach is only meaningful for persistent
 applications that need fast access to C-library functions, or that need
 low level API access for data modification (like digitizing).

 And this is not only vector and raster digitizing, this is also new
 scatter plot tool and in fact the whole `g.gui.iclass`, `nviz` (which is
 unfortunately more complicated) and of course everything temporal-related
 (everything started to be temporal-related).

 > My intention to write the RPC server was to make the temporal framework
 usable in persistent applications and to be as fast as possible.

 I'm not sure how the speed of `RPCServer` compares to module call but the
 speed is not the only advantage. Fine control of what is called and a
 smoother interface (possibly, depending on wrappers) is the other
 advantage. Calling subprocess from GUI for every single task and parsing
 its output is cumbersome.

 > The pyGRASS interface is well designed for module programming not for
 persistent applications. Otherwise each C-function call should be handled
 via RPC. From my point of view and some tests that i made slows the RPC
 approach the processing significantly down.

 So, in the next step, we need pyGRASS-like interface which is fail safe
 and temporal library which is faster?

 > Running the script will show that calling functions from a dict is 50
 time faster than using a pipe with a subprocess.

 It seems that this is something we need to take care of. And this is
 something what my factory pattern suggestions is trying to address.

 We would need to create two sets of class with identical interface. One
 using `RPCServer` (safe) the other calling ctypes directly (fast). Objects
 should be created by factory, so that the factory will put the `RPCServer`
 into the objects, so the user does not take care of it. Maybe in Python we
 can go beyond the classic factory pattern and create also the
 `RPCServer`-dependent classes from the classes calling ctypes directly.

 I realize that ''some code'' would be appreciated but I cannot dive into
 this more now.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2134#comment:9>
GRASS GIS <http://grass.osgeo.org>