[omniORB] Thread and connection policy for very large configurations

[Duncan Grisby]

On Wednesday 2 April, Serguei Kolos wrote:

[...]
> >Perhaps you could develop a
> >patch for using poll(), and make it either a build-time or run-time
> >configuration option.
> >
> This is probably a good idea. But what happens when the new version of the
> omniORB appears? I guess I'll need to rewrite my patch.

If you come up with a clean patch, I'll integrate it with the
distribution, so you won't have to track changes.

> Could it be done in a different way - could the OMNI itself provides
> an API for setting up a custom implementation of the socket
> multiplexor at run-time?

An API is an option, but the select loop is very much on the critical
path for thread pooled calls. Adding an API would possibly add more
overhead that is acceptable, for a feature that isn't required by the
vast majority of omniORB users. I think I would prefer compile time
conditional code.

> In this case I can write my own multiplexor based on the poll and set it up
> if necessary instead of the default, select based one.
> Alternatively one could say that the SocketCollection class (which
> implements the socket multiplexor) is the API that one could use to
> implement his own multiplexor.

SocketCollection is a base class used by transport implementations, so
it doesn't provide a suitable way to change its functionality.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --