Re: ORBit mail 3 - Vtable layouts

[Owen Taylor <otaylor gtk org>]

Phil Dawes <philipd@parallax.co.uk> writes:

> Evaluating the benefits of vepv vtable layouts
> ----------------------------------------------
> 
> As I understand it, ORBit currently supports a vtable layout
> equivalent to the example below:
> 
> interface intf3 : intf1, intf2 {};
> 
> 
> Object      VEPV            EPVs
> ------     ------         ---------
> 
> vepv ---> intf1_epv -------> op1
>           intf2_epv ----.    op2
>           intf3_epv --. |
>                       | `--> op3
>                       |      op4
>                       |      op5
>                       |
>                       `----> op6
> 
> 
> But given the casting implementation in Upcasting.txt, why not simply
> eliminate the middle layer and have the server set up a number of
> seperate method tables, and return a pointer to the appropriate one:

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.

[ 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.

Regards,
                                        Owen