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

 Replying to [ticket:2134 wenzeslaus]:
 > 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?


 I think that a is great to have a RPC integrated in GRASS, and could be
 useful for many reasons, but personally, I think that to solve the problem
 of the G_fatal, we should handling directly the C signals. Of course it
 will not work in case of occurring of a Segmentation Fault, and in this
 sense I think that we need a RPC approach, but speaking about pygrass,
 that it is a lower API, I think that would be great to be able to manage
 the C signals.


 We already discuss about this topic (#1646), and I don't know If I should
 discuss this here or in the previous ticket, any way, maybe we should
 consider to integrate in the GRASS source a fault handler, I found this
 project [0] that maybe could be integrated in GRASS, I believe there is
 some issue with the License [1] that is under "BSD (2-clause)"[3], so I'm
 not sure it is possible to copy directly inside GRASS, but maybe we can
 write something from scratch with the same logic.


 Or as already suggested by Glynn (#1646) wrap the G_add_error_handler,
 maybe given a more abstract and easy to use interface, and possibly that
 avoid to expose the users to ctypes. Do you think that would be feasible?


 Pietro

 [0] https://github.com/haypo/faulthandler
 [1] https://github.com/haypo/faulthandler/blob/master/COPYING
 [3] http://opensource.org/licenses/BSD-2-Clause

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