[omniORB-dev] Issue with omniORB select loop implementation

[Duncan Grisby]

On Friday 3 September, Jonathan Biggar wrote:
> The SocketCollection::Select() function has a built-in hardcoded 50 
> millisecond timeout.  This causes major problems with an application 
> that I'm developing that must run on IBM 390 series hardware using linux 
> running under VM.
> 
> Every linux virtual machine that runs an application using omniORB will 
> wake up every 50 milliseconds, decide there is nothing to do and go back 
> to sleep.  If more than one omniORB application is running on the Linux 
> instance, the problem is compounded.  This activity prevents the linux 
> instance from being descheduled by VM because it thinks the instance is 
> always busy.  Needless to say, this isn't playing nice in the VM world.
> 
> Can anyone give me insight into the need for the 50 millisecond timer in 
> the first place and what might happen if I changed it or removed it 
> entirely?

The time is used for two things, only one of which is actually
necessary on Linux. When in the thread per connection mode (the
default), just before the thread dedicated to a connection makes an
upcall, it marks the thread as "selectable" by the thread doing
select. The next time the thread wakes up, it starts watching the
connection, in case the client sends interleaved calls on a single
connection. That way, in the common case that a client serialises
calls on each connection, there is no thread cross-talk, but the
system still copes with clients that interleave calls.

The other thing it's used for is that on some platforms (notably
Windows), it's not feasible to interrupt the thread doing select, so
there's no way to add new connections to be watched. Having the fairly
short timeout means that that's not too bad. On Unix platforms, a pipe
is written to to wake up the select.

There's no particular reason for the timeout being hardcoded. It's
just that nobody has ever seen the need to change it before. In most
cases, on Linux, you could safely set it much larger. If you produce a
patch to add a new configuration parameter for it, I'll include it in
the release.

Cheers,

Duncan.

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