Limitation of collocation

chaukmean

Hi,

I read the ICE documentation and it seems that ICE doesn't actually support collocation :
- if two objects share the same Communicator, the "communication" bypasses the object adaptor, thus the client thread is used to execute the servant code... This also prevents the use of AMI and AMH ... It's a very restrictive or extreme collocation strategy
- if two objects use different Communicators, the communication behaves like the objects are hosted by different processes with the implied marshalling/demarshalling ... There is no collocation at all here.

Am I right ?
Do you intend to support a more usual collocation strategy that bypasses the marshalling/demarshalling process but still uses the object adaptor ?

Happy New Year to Zero C team !

Chauk-Mean.

marc

Two communicators are a way to completely separate two programs that use Ice in one executable. I think it's only logical that in such case, there is no collocation optimization, as collocation optimization can have side effects (as described in the manual). If you do not wish to completely separate two Ice programs in one executable, just use only one communicator. This then allows you to use collocation optimization.

AMI and AMD rely on certain threading properties which are provided by our thread pools. E.g., if you send a request with AMI, then such request cannot be dispatched in the caller thread (as it's done with collocation optimization), but must be dispatched and the result be returned in a different thread (otherwise it wouldn't be asynchronous). The thread pool, however, is strongly coupled with the network layer for efficiency. It's a leader-follower model, with the leader always waiting in select(), and is therefore not suitable for dispatching collocation-optimized AMI callbacks. We could add a special thread pool just for such cases. However, this would increase complexity in Ice, as we would introduce a second collocation optimizaton mode, with different threading properties.

chaukmean

Thanks for the reply.

I completely understand that you take care to keep the implementation of ICE as simple as possible. Nevertheless, efficiency and performance may be worth increasing the complexity of ICE code .
In the context of component based development, it is useful to deploy some components as a local assembly (collocation of connected components) in order to improve performance.
Having the full power of ICE (AMI, AMD) but without the collocation optimization doesn't seem to be a solution in this context.
Likewise having a collocation optimization but without the full power of ICE doesn't seem to be good solution either.

Anyway, I like ICE.

Chauk-Mean.