Re: ORBit mail 3 - Vtable layouts

[Owen Taylor <otaylor gtk org>]

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

> Lauri Alanko wrote:
> > 
> > [reply-to directed to orbit-list@cuc.edu, that's where this belongs..]
> > 
> > On Mon, 15 Jun 1998, Phil Dawes wrote:
> > > 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.
> > 
> > "Not distributed"? You mean an object that cannot be invoked outside its
> > process context? If you want something like that, why use CORBA?
> > 
> 
> Because you might have objects written in different languages.
> I didn't mean that the object *couldn't* be invoked outside their
> address space. I just meant that the most likely use-case for such a
> component is to execute in the same address space as its client.
 
If you use function-call based short-circuiting for interlanguage
communication, then you need to compile C based stubs for each
interface. Which is (from my perspective) highly undesirable.

The "right way" to do interlanguage communication is most likely
to marshal into a buffer then demarshal. And once you except
this penalty for inter-language communication, then it probably
isn't worth shaving microseconds off your intra-language calls.
 
> > > 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.
> > 
> > Frankly, I don't understand all this fuss about optimizing in-process
> > calls at any costs. If you have objects that are going to communicate
> > in-process, and you want it fast, you have no reason to use CORBA anyway.
> > You can have the implementation code call other objects' implementation
> > code directly and forget all this reference/object adapter fuss.
> > 
> 
> Yes, but you might wan't to be able to use different languages within
> the same address space - that's somewhere that a mapping like CORBA
> makes things simpler
> 
> Basically I'd like to have something along the lines of COM for gnome,
> and CORBA seems like a fairly good fit.
> 
> > You can't bypass all marshalling with in-process CORBA objects, at least
> > if they use vanilla POA. Calls can be forwarded, a POA could change state
> > and all that.. You can't just bypass the POA, at least if you want
> > conforming code.
> 
> That's a shame. I've had a short read through the spec and I couldn't
> find any reason why you can't. I'll do some more reading tonight.

Some reasons off the top of my head:

 - The POA could have the policy NO_RETAIN, which means that
   application is queried for a servant on each request.

 - The servant might have been deactivated in the meantime.

The POA spec actually mentions the inability to short-circuit
explicitely. This doesn't mean that intra-language performance
is going to be slow (centainly not when compared to inter-process
communication times)  - it just won't be blazingly fast. CORBA
and especially the POA are somewhat heavy-weight solutions intended
for distributed computing. 

> > Of course, you can have an extension, or custom OA, that is optimized for
> > in-process communication, but to me at least that seems rather
> > secondary at this stage..
> > 
> > As I said, if you want in-process performance, you don't want to use CORBA
> > anyway..
> 
> But I do want different languages in the same address space. There
> aren't many other choices AFAIK (com or ilu).

To my understanding, COM is quite poorly designed for 
multiple-language use. 

ILU does not attempt to do macro based short-circuiting of function
calls. It's client-side stubs look like:

void yyy_A_foo (yyy_A _handle, ILU_C_ENVIRONMENT *_status)
{
  void (*_f)(yyy_A, ILU_C_ENVIRONMENT *);
  _f = (void (*)(yyy_A, ILU_C_ENVIRONMENT *)) _ILU_C_FindMethod (_handle, _yyy_A
__ILUType, 0);
  _status->_major = ILU_C_NO_EXCEPTION;
  _status->ptr = ILU_NIL;
  _status->freeRoutine = (void(*)(void *)) 0;
  _status->returnCode = (ilu_Exception) 0;
  (*_f)(_handle, _status);
}

Regards,
                                        Owen