Re: Can we do VTable short circuiting at all?

[David Wragg <dpw doc ic ac uk>]

> It is now looking pretty certain that we can't do inproc vtable
> short-circuiting within the POA and still remain conformant. (e.g.
> section 9.2.10)

I agree. In general, it is not possible to have clients directly call
object implementations under POA.

This isn't just due to the POA spec; if clients directly call object
implementations then it is impossible to move an object implementation
out of a process while there are intraprocess references pointing to
it. (I'm not suggesting that the ability to move object
implementations between processes on demand is something needed for
ORBit in the near future, but it is something that one day could be
very neat.)

However, the overheads of conforming to the POA spec aren't huge. Even
doing it the simple, really portable way*, on modern machines the
overheads won't be visible below hundreds of thousands of requests per
second.

*) By which I mean, the function pointers in the vtable actually point
to stub functions which look like:

   if (obj->short_circuit_ok_flag)
      <call method of obj->real_obj>
   else
      <do all the fiddly POA stuff>


> But this is still something I'd like to be able to do with orbit. This
> is because orbit is the gnome orb, and as such is likely to be used
> primarily for local and in-proc objects.

But as you say, it would be nice to have "short-circuiting" in many
circumstances, where objects are intrinsically fixed in a single
process. A graphical component, for example. (Under X graphical
components could in principle be moved between processes, but I don't
currently see huge benefits in being able to do so, and there might be
problems with toolkits).

> Could this be done through another object adaptor which deals only in
> local proc shared library objects? 

I think this is definitely the right way to go. Of course a good POA
implementation should be provided, but the POA spec is based on
presumptions about it's intended use. Thus it would be silly to force
programmers to use it in _all_ circumstances, which may be very
different from those expected by the POA spec authors.

> [snip]


David Wragg.


P.S. I do still intend to contribute to ORBit, but I'm writing code
before I kick up a fuss again ;-)