[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                           |  
--------------------------------------------------+-------------------------
 After discussion with Soeren, I'm opening a ticket with a request for a
 general exit-safe interface to C libraries.

 The purpose of this is (citing Soeren)
 > to reduce the direct ctypes usage in the temporal
 > framework, so that GUI elements can easily be implemented on top of
 > it, without the risk to be exited by a `G_fatal_error()` call. But i
 > don't want to use the script interface to avoid its module execution
 > and parsing overhead, which slows things massively down.
 Moreover, it protects the main application in case of segmentation faults.

 The r58201 (#2127) and r58249 revisions provide `Messenger`
 (source:grass/trunk/lib/python/pygrass/messages/__init__.py) and
 `CLibrariesInterface`
 (source:grass/trunk/lib/python/temporal/c_libraries_interface.py) classes
 which implements the idea of server (a separate process) executing ctypes
 (C library) functions (remote procedure call (RPC)). One is PyGRASS
 interface for GRASS messages the other is the interface for GRASS C
 functions needed by temporal framework.

 One issue I see is that we need to implement such a class for each use
 case. One for PyGRASS messages, other maybe for PyGRASS itself, for
 temporal library, for GUI vector digitizer, for scatter plot... Is there a
 way to create a general interface, or generated interface or make the
 implementation simple?

 The other issue is with implementation itself. Each class use a bit
 different implementation to call functions. However, generally, some
 identifiers are mapped to the ctypes functions. One issue is that it slows
 down the function call. The other is that it is tedious (and error prone)
 to implement (you need to create the mapping). And finally what is always
 judged in Python code: it is not Pythonic (whatever that means, e.g. nice,
 intuitive, straightforward). This of course highly relates to the first
 issue.

 Related documentation currently accesible from:
  *
 http://grass.osgeo.org/programming7/namespacepython_1_1temporal_1_1c__libraries__interface.html
  *
 http://grass.osgeo.org/programming7/classpython_1_1temporal_1_1c__libraries__interface_1_1CLibrariesInterface.html
  *
 http://docs.python.org/2/library/multiprocessing.html#multiprocessing.Connection

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