Re: [orbitcpp-list] questions

[Phil d. <ph...@us...>]

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> got some questions regarding the runtime:
> 
> * why the extra op_marshaller method in the skels? why not everything in
> one skel wrapper?

It's a multiple inheritance issue:
For each call the skeleton operation needs to cast the void* pointer
into the appropriate C++ skeleton type. With multiple inheritence
(virtual inheritance) C++ relies on the cast to do the appropriate
vtable thunk. This means that you need a function per interface per
operation to ensure that the void* c++ servant pointer gets casted to
the right C++ servant type (you cant share them).
The marshalling code for inherited operations is common across all the
interfaces, and so gets factored out into a single op_marshaller
function.

If you grab a copy of ORBit-C++ and compile the diamond-inheritance test
and look at the skels file, you will see how this works. (mail me if you
want me to send you the C file and save you faffing about with
PYTHON_PATHs ;-)

> * are you sure the environment singleton does not cause reentrancy
> problems (e.g. a calls b and b calls a back before returning) apart from
> being not thread-safe (aka: is creating the env on the stack much more
> inefficient?)

You're righ, it will cause reentrancy problems and it isn't thread safe.
I wrapped it in an accessor method in order to defer the decision on how
to create/manage environments until later. e.g. maybe some pooling will
yield the best performance/thread safety compromise.
Creating and initialising envs on the stack may be more efficient as
well.

> * what specifically was the problem with keeping servants on the stack?
> (it worked for o2cpp)

I can't remember the specific reason. The symptom was that when the c++
implementation object was created on the stack, we got a segfault.
Creating the C servant on the heap fixed this.
If we can get away with creating c servants on the stack then this is
obviously preferable from a performance standpoint.

> * shouldn't we prefix every non-spec method in public inheritable
> classes by something like _orbitcpp to reduce the risk of name clashes?

Sounds reasonable.

> * shouldn't we reindent this with indent-namespaces on? (if yes, go
> ahead, see .astylerc from other mail)

Okay. I don't mind either way.

Cheers,

Phil.