#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>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
