[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 huhabla):

 Pietro and i investigated the possibility of a PyGRASS vector RPC
 interface in more detail off-list. We came to the conclusion that the
 design of PyGRASS does not allow the implementation of a RPC interface as
 suggested in this ticket. The main problem is that the most important
 PyGRASS vector geometry classes make use of C-library structures
 internally to massively speed up processing. The vector C-library
 structures (Map_info, line_pnts, line_cats, ...) are managed by the vector
 C-library using dynamic memory allocation. Such structures can not be
 automatically serialized (pickled) by Python. But instances of the
 geometry classes (Point, Line, Isle, Area, ...) must be exchanged by the
 RPC interface for reading and writing of vector maps. To allow the
 exchange of geometries all these classes must be rewritten and reduced in
 their functionality. All functions that may call G_fatal_error() must be
 removed from the geometry classes. An additional abstraction layer must be
 implemented to convert the line_pnts and line_cats data into picklable
 Python objects and vice verse.

 Making PyGRASS RPC conform will result in much slower vector processing
 and reduced functionality. The only benefit would be that persistent
 applications, like the GUI, can use PyGRASS via RPC.

 However, Pietro and i came to the conclusion that the effort to modify
 PyGRASS to be RPC conform is to large and the benefits to low. We suggest
 a dedicated vector editing RPC interface that calls the vector C-library
 functions in the RPC subprocess directly, or that make use of PyGRASS in
 the RPC subprocess but converts the geometry objects into picklebale
 Python objects.

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