Re: ORBit mail 3 - Vtable layouts

[Phil Dawes <philipd parallax co uk>]

Owen Taylor wrote:
> 
> I haven't looked at ORBit recently, but the scheme you describe
> above is required by the C-language binding for CORBA. So changing
> it isn't an option if we are trying to make a standard CORBA ORB.

Yes, but only in the POA servant code. There is no reason AFAIK that the
stubber can't generate another set of vtables for use by an inproc
client since the client mapping only requires the programmer uses a
pointer to CORBA_Object. (although this is an extra space overhead.)


> 
> [ alternate vtable layout omitted ]
> 
> > And the casting macro simply calls a defined function on the server
> > which returns the appropriate epv according to the Repoid of the
> > interface.
> >
> > #define CORBA_CAST_INTF1(_o) {_o->epv->CastTo(ID_OF_INTF1), _o->obj}
> > #define CORBA_CAST_INTF2(_o) {_o->epv->CastTo(ID_OF_INTF2), _o->obj}
> > #define CORBA_CAST_INTF3(_o) {_o->epv->CastTo(ID_OF_INTF3), _o->obj}
> 
> Wait a second... The C mapping has no casts!
> 
>  CORBA_object o = [ ... look up in the naming service ... ];
>  Foo_frobate (o);
> 
> Is perfectly legal code. The mapping says that Foo must be defined to
> CORBA_Object. So, Foo is available for "decoration" (as the
> specification says), but must be the same as CORBA Object.
> 
> The multiple-inheritance problems you are describing are basically yet
> another reason why macro-based shortcircuiting is incompatible with
> the the CORBA C mapping.
> 
> The non-macro implementation is straightforward:
> 
> void
> Foo_frobate (Foo foo, CORBA_environment *env)
> {
>   /* Look up the servant using PortableServer::reference_to_servant or
>    * ORBit-internals equivalent */
> 
>   if (servant != NULL) /* short-circuit */
>     {
>       int i;
> 
>       ORBit_ServantPrivate *private = servant->_private;
>       Foo__epv *epv = (Foo__epv *)servant->vepv;
> 
>       for (i=0; i<private->nvtables; i++, epv++)
>         {
>           if (((Orbit_EpvPrivate *)epv->_private)->type == Foo_typecode)
>             {
>               epv->frobate(foo, env);
>               return;
>             }
>         }
> 
>      /* raise a suitable exception */
>    }
> 
>   /* Do a full invokation */
> }
> 
> Yes, that is going to be slower than the macro scheme, but if
> your interface design is at all suitable for being used in
> a distributed environment (and if it isn't, why use CORBA), then
> the overhead should be pretty unnoticeable.
> 

Agreed. Unfortunately the whole point of inproc components is that they
are not distributed. Areas where this could be of use are e.g. plugins
for applications (e.g. gimp etc..), and in a component architecture.
Witness how COM is used on OLE in windows for example.

Unfortunately the corba spec is not designed to be used with inproc
objects (it doesn't define a binary standard), so I was hoping that we
could develop one around the C-language POA mapping. Unfortunately it
looks like this requires using casting macros which aggregate to a
'queryinterface' style function which as you mention goes against the
corba spec.

However this is a small misnomer, and distributed client code would be
using an empty macro anyway since the marshalling code would take care
of upcasts implicitly. 

Cheers,

Phil.


-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.