[omniORB] no reply after a week, so asking again about co-locationoptimizations

[Jeff Graham]

David Riddoch wrote:

> On Tue, 11 Apr 2000, Jeff Graham wrote:
>
> > Q1. What colocation optimizations exist in Omni3?
> >
> >         a. 1 computer with 1   cpu,   1   process, 2+ threads
>
> Within process invocations are made as direct function calls.  If the
> client uses DII or the servant DSI then the call goes through the loopback
> interface.

Direct function calls is what I would expect since the threads would share the
same address space.

But I noticed in the omni report  "The Implemetation
of a High Performance ORB over Multiple Network Transports" (TR.98.4.pdf)
that there exists several other optimizations of which I am especially
interested in
the "shared memory" transport and the "SCI" transport.

Do you know if these are supported in Omni3 and how to force their use, since
according to Table 2
page 12 of the report, the shared memory transport is faster than the local
loopback device and the
SCI transport is superior in some aspects.


> >         b. 1 computer with 1   cpu,   2+ processes
> >
> >         c. 1 computer with 2+ cpus, 2+ processes
>
> Invocations on objects in another process on the same machine are made
> through the TCP loopback interface.  The number of CPUs does not change
> the mechanism, just how many processes/threads can run concurrently.
>
> > Q2: Any specifics on how to take max advantage of these (i.e., are
> > there any
> > compiler switches, command line args, build configurations, etc to
> > use)?
>
> There is an option to limit the number of connections omniORB will spawn
> between processes, which in turn can limit concurrency
> (omniORB::maxTcpConnectionPerServer).  Other than that there is no
> control.

Thanks,
Jeffrey