[omniORB] local invocations

[Stephen Davies]

Not sure that this belongs in this thread/list, but anyway:

On Thu, 8 Nov 2001, Duncan Grisby wrote:

> For the real speed freaks (Hi Stefan and Stephen!) I've just checked
> in a shortcut mechanism for in-process colocated calls. This reduces

I have downloaded the cvs, this is the first time I tried omniORB4, and am
having some problems.

First off omniNames triggers assertion faults whenever a client tries to
use it: eg3_impl, nameclt list and the berlin server all cause this.
 file: callHandle.cc
 line: 127
 info: pd_localId
Cannot resolve the root context.
Have you set up the configuration file properly?

There is an error in the sample.cfg file: bootstrapAgentHostname should
not have quotes, as it does name lookups verbatim, including quotes, which
obviously fails (and caused me no end of headaches...)

To continue I reinstalled the omniORB3 .deb just so I had a nameService
running. Everything else still has paths/env vars set to use 4.0 and they
complain about the cfg file's version but that's okay.

The berlin C++ demo client causes another assertion fault:
 file: ../omniInternal.cc
 line: 634
 info: pof
Segmentation fault

To continue I ran the C++ demo client from an old omniorb3 build, which
works with the 4.0 berlin server okay (go corba!:)

The berlin server works fine (now that I have the nameService stuff
working), until I try using the shortcut poa. If I do, I get a lockup
waiting for a mutex. I'm not sure if I did it correctly, but I took the
code from the wiki and used the new shortcut_poa everywhere the rootpoa
was used previously, ignoring all issues with threading etc..

#0  0x409f7a0e in sigsuspend () from /lib/libc.so.6
#1  0x400f3629 in __pthread_wait_for_restart_signal ()
#2  0x400eff52 in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x40aef6e6 in omni_condition::wait ()
#4  0x406b3e2b in omni_tracedcondition::wait ()
#5  0x406a68b0 in omni::omniOrbPOA::synchronise_request ()
#6  0x406a358e in omni::omniOrbPOA::dispatch ()
#7  0x40689bb8 in omniLocalIdentity::dispatch ()
#8  0x4069459f in omniObjRef::_invoke ()
#9  0x402612d3 in Warsaw::_objref_LayoutKit::create_stage ()
#10 0x08055eb1 in main ()

This is the first call into the object. There are only three other threads
running: a pthread manager, omniorb's socket listener and a berlin thread
pool manager. All three are idle doing their thing, not interfering with
the object in question. If I switch on all logging I get this:

[2.95727:0:layout]      About to create LayoutKit
omniORB: (0) Adding root/shortcut<33554432> (activating) to object table.
omniORB: (0) State root/shortcut<33554432> (activating) -> active
omniORB: (0) Creating ref to local: root/shortcut<33554432>
 target id      : IDL:Warsaw/Kit:1.0
 most derived id: IDL:Warsaw/LayoutKit:1.0
[2.95776:0:layout]      Created LayoutKit
omniORB: (0) POA for root/shortcut<33554432> (active) in HOLDING state;
waiting...

I noticed that not all objects were created in root/shortcut (I looked at
one and it calls _this() in the constructor, which I guess uses the root
poa). This is the first call into an object in the root/shortcut poa.

I tried to stepi through the layout->create_stage() call, and it went
through many many mutex locks/unlocks and other crap before I lost count.

On a brighter note, not using the shortcut seems marginally faster than
3.0, but only from memory (I didn't write down any numbers)

TIA,
Stephen

   //------=[ Chalky (Stephen Davies) -- Chalky@null.net ]=------\\
  //-----=[ Powered by Linux -- "Escape the Gates of Hell" ]=-----\\
 //----=[ CEED : Agilent Technologies - RouterTester Project ]=----\\
//-=[ Programmer(C/C++/Java) and 4th Year CSE/CS Student at RMIT ]=-\\