Re: [Openhpi-devel] Plugin interface

[James K. <sou...@ke...>]

Louis Zhuang wrote:

> In your proposal, it seems there are too many mapping assumes between C
> and C++, they depend on ABI, compiler, machine and even compiling-option
> and compiler version... I can not load the plugin_cpp on my Redhat 8.0
> with gcc 3.2

ABI compatability will always present a problem for a dynamically 
loadable plugin model.  In this example, they happened to change the 
vtable offset.  It doesn't matter what you do in your code, if the 
compiler people muck with the ABI, your code (especially dynamically 
loadable code) has a chance to be fubar as a result.

Any data structure will have compile-option compatability issues, 
especially when users start to salt their structures with data; if they 
have single byte alignment and put a piece of data between two method 
handles, wham-o.  So, in that regard we may have to specify certain 
options as being required in order to support calling into openhpi 
interfaces.  Using a macro'd approach helps enforce restrictions on the 
user and also hides them from the internal representation of the vtables 
required by the method invocators.  It also helps in the creation of 
strict interfaces where the caller doesn't know any internal details 
beyond the method signatures.

> So I perfer to find an more elegant way to allow people write C++ plugin
> if they insist on it. Maybe something like following code

The problem with this is there are now two levels of indirection 
required for every method invocation implemented in C++.  By allowing 
the direct method mapping through macros, we allow creation of the 
plugins in either language with no performance penalties, and abstract 
the user from having to know the internal semantics of setting up the 
vtable mapping.

This also allows us to use an IDL compiler for creation of the C and C++ 
stub code for the interface in and out of the objects.  While not 
important now on single machine communication, when we add an RPC 
mechanism, we can extend the IDL to include marshalling as well and then 
we have remotable interfaces without having to craft protocols or 
structures for each interface.

One final note; the proposed method I sent out previously has the added 
benefit of binding the passed interface with an object 
instantiation--where an opaque object reference is passed to every 
method call as the first argument.  This allows a single method 
declaration to handle calls for multiple objects.  The solution below 
requires you to implement a separate sample_func1 for every unique 
instance of an object you want to return.  You can solve this by passing 
a pointer to the structure instance as the first argument of every 
function, but this adds even more overhead to call stubbing to C++, plus 
the end result is that you have almost exactly what I had proposed.

To correct the problem you are seeing on RH 8.0, I've attached a new 
archive.  It simply changes the ABI for GCC 3.0 and greater, and changes 
plugin_cpp to build with g++ instead of gcc.  I've tested on RH 7.1, 
7.3, and 8.0.

James

> plugin.cpp
> --------------------
> class CSample {
> 	func1();
> }
>
> CSample::func1()
> {
> 	...
> }
>
> static CSample sample;
>
> extern "C" { //glue C++ code into plug interface
> sample_func1()
> {
> 	sample.func1();
> }
> struct interface sample_interface ={
> 	.func1 = sample_func1
> };



-- 
----- ----  ---   --    -       -         -
James Ketrenos            web : http://ketrenos.com
My words are my own.      msn : ket...@ho... <email ignored>