[omniORB] [PATCH] "Safe" shortcut calls

[Nathaniel Smith]

On Mon, May 13, 2002 at 11:32:32AM +0100, Duncan Grisby wrote:
> On Friday 10 May, Stefan Seefeld wrote:
> 
> > What is your intention concerning such an addition ? Since all overhead
> > can be avoided (by not using specific flags with omniidl), is there
> > any reason *not* to include the patch into the mainline after the 
> > release ? I acknowledge that it is quite some work to incorporate it...
> 
> I certainly think it's worth including in omniORB 4.1, or whatever the
> next major release is called. From a quick look at the patch when it
> was first posted, I think it does add a little bit of memory overhead
> even if you're not using it (I might have mis-remembered that,
> though). I want to look into whether it's possible to avoid that, and
> to generally think about how these things should fit together.

Yes, it adds 1 pointer member to the omniObjTableEntry class.  This is
only about 4% extra overhead for each activated servant, at least on
x86 (and it's not per-reference or anything icky like that).  This
could be avoided by storing these pointers in a separate table
somewhere (a map<omniObjTableEntry*, omniShortcutManager*>,
basically), but then lookups get kind of expensive.  I suppose it
might be acceptable overhead -- omniObjTableEntry's only need to get
at the shortcut managers when turning on shortcuts for a new
reference, and when deactivating themselves -- but this is a bit of
complication that I didn't want to do for a mere 4%, when I had no
idea whether 4% was something you were worried about :-).

-- Nathaniel

-- 
  /* Tell the world that we're going to be the grim
   * reaper of innocent orphaned children.
   */
-- Linux kernel 2.4.5, main.c

This email may be read aloud.