Re: Reason for omniORB imposed latency when handling multiplexed requests on a server connection?

On Friday 28 October, Jonathan Biggar wrote:

> I've noticed that giopServer::notifyWkPreUpCall always calls
> setSelectable with now = 0.  This means that the select loop is not
> immediately notified that the server connection is readable.  Since
> the main select loop has a fixed wakeup timeout of 50ms, up to that
> amount of latency is seen before a second request on the same server
> connection is recognized and processed.
> 
> Is there a particular design reason for this added latency?  Otherwise
> I'm strongly tempted to change notifyWkPreUpCall to set now = 1 and
> get immediate service for the connection.

It's a balance between different concerns. There are two common usage
patterns that influenced the design. First, it is often the case that
each connection is used by only one client thread at a time. In that
case, there won't be any interleaved calls. The second common pattern is
that a client sends lots of small oneway calls that complete quickly on
the server. In that case, several calls can arrive very rapidly, and
it's best to service the calls from just one thread rather than allowing
an explosion of threads to handle all the calls.

Also, signalling the select thread to wake up immediately is a pretty
heavy-weight thing, and leads to thread switching during operation
dispatch. In most applications, it's rare to need the connection to be
immediately watched, so it's left to the timer.

Having said all that, if it's better for your application to always kick
the select thread in notifyWkPreUpCall, I don't think it'll break
anything to change the code. Note that on Windows setting now to true
has no effect since it doesn't have a convenient way to wake up the
select thread.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --