#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):
I have implemented a new RPC server that can call any kind of Python
function directly in the server subprocess. The server subprocess will
restart in case the provided Python function was terminated (segfault,
exception, G_fatal_error, ...).
The Python file with the new RPC design is attached. Please have a look at
the doctest examples that demonstrate how to use the RPCServer.
The RPC server supports two methods to call remote functions {{{
call(function, args) }}} and {{{ call_no_wait(function, args)}}}. The
{{{call()}}} function will always wait for the server to commit the return
value of the called Python function although the function may have no
return value. The {{{call_no_wait()}}} function will not wait for the
Python function to finish and therefor not return any return value of the
called Python function.
Example:
{{{
def info(args):
message = args[0]
libgis.G_message(message)
def raster_map_exists(args)
name = args[0]
mapset = args[1]
mapset = libgis.G_find_raster(name, mapset)
if mapset:
return True
return False
rpc = RPCServer()
rpc.call_no_wait(function=info, args=("This is a message",))
ret = rpc.call(function=raster_map_exists, args=("test", "PERMANENT"))
}}}
I am still not sure about the best Python caller function design. Should
the error return values of GRASS C-library functions be returned, or
should an exception be raised?
Any suggestions are welcome.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2134#comment:1>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
