Re: On GIMP and CORBA

[Lauri Alanko <lealanko cc helsinki fi>]

On Thu, 20 Aug 1998, Felix Bellaby wrote:

> I believe that the stub functions which marshall calls in efficient
> CORBA implementations check whether the object's implementation is
> resident in their own address space before doing any marshalling.
> (Objects obviously have to maintain references to where their
> implementations reside). When the implementation is in the same
> address space there is no need to marshall and demarshall the
> code. Indeed, the design of the POA in CORBA 2.2 means that there is
> no need to create a new stack frame: the implementation code can
> simply take over and return from the frame. This means that
> invocations on CORBA objects in the local address space are only very
> slightly slower than direct C function calls :-).

Whatever is "slightly" lower.. keeping in mind the infamous note at
9.2.10. Still.. it's good programming practice to have lots of small
functions. Making every member access go via the ORB would be unacceptably
slow, and only marginally useful in practice, in this case.

> The Fresco toolkit is able to implement its WIDGETS entirely in CORBA 
> without unacceptable inefficiency (it does cheat a bit by using a
> version of CORBA that is unable to make network connections!!)

Well, if it doesn't support IIOP, it's no real CORBA..

> CORBA supports the dynamic linking of implementation code into the
> address space of running executables as part of the standard. Systems
> without dlopen do not fully support CORBA. I suppose you could add
> memory sharing into the stubs and skeletons on those systems.

Chapter and section, prithee.


Lauri Alanko
la@iki.fi